Sizing : Initial Estimate - Acme Small

Based on the information received from ACME Small Co. the following is a reasonable estimate of the hardware required to service the usage requirements specified.

ACME Small Co. have stated that their user community could range from 10,000 to 30,000 users, however they also indicated that it was their policy to create accounts for every employee at the companies that subscribed to their services. Not every employee of the company will use the ACME Small Co. portal service. Given this factor a weighting of registered users to calculate the page model is a reasonable approach. ACME Small Co. have also indicated that currently their total page request rate in a 24 hour period is 7,000 pages. Assuming that this number of page requests is generated by a user-base of 10,000 users this gives an extrapolated page request rate of 0.081 reqs/sec and an extrapolated user activity rate of 0.024%

If we assume that 

• a site may have 10000 registered users
• of those 10000 users 0.024% are making page requests at any one time
• of the 2.4 requestors each one clicks twice every 60 seconds
• this equates to 0.081 page requests per second

If the user community grows to 30,000 with the same extrapolated usage model the result would be a page request rate of 0.24 req/sec or 21,000 in a 24 hour period.

That is the definition of concurrency we use within Portal development, it is not really reasonable to use the term concurrency as none of the users are really concurrent because of the disconnected manner in which HTTP requests are made and destroyed.

Given the following topology recommendation, there follows some hardware implementation suggestions for Linux and Solaris based solutions.

Linux Solution

Solaris Solution

Diagram Definitions

• Machine A

  This machine is a hardware load balancing router that will handle the initial routed requests from the internet. This is commonly implemented using vendors like F5 (BigIP) and Cisco (Local Director). This is not a mandatory but recommended requirement. Using an LBR will ease any further expansion of the system design by ensuring that the infrastructure will not to be rewired should any further middle-tiers be added to the solution. It is possible to designate one of the Webcache machines to act as an LBR for the Webcache cluster, although this will detract from the Webcache performance of that machine. Should SSL be required it is possible to configure a HW LBR to implement SSL encryption on outgoing traffic thus alleviating this expensive step from the iAS software.
   

• Machine B

  This machine will run the OracleAS Webcache and Oracle HTTP Server components including OC4J_Portal and mod_plsql. It will be configured as part of a Webcache cluster with Machine C.
   

• Machine C

  This machine will run the OracleAS Webcache and Oracle HTTP Server components including OC4J_Portal and mod_plsql. It will be configured as part of a Webcache cluster with Machine B.
   

• Machine D

  This machine will be the infrastructure component of the implementation. Components on this machine will include the infrastructure OHS, LDAP processes and the infrastructure repository installed in an Oracle 9.0.1.3 DB. This infrastructure install will be a standard implementation of the AS infrastructure and as such will contain Portal, SSO, Enterprise Manager and OID schemas.

Further Considerations

Growth

This architecture provides no growth beyond the capacity expressed by ACME Small Co.. If the login rates, usage models or general data volumes grow above those previously expressed then the hardware outlined here will need to be enhanced and/or added to.

If the volumes assumed are reduced then it may be possible to reduce the implementation architecture to one (1) middle-tier machine and one (1) infrastructure machine. For the given volume load it is not recommended to go below this lower limit.

Security

This architecture provides no explicit security requirements beyond that provided out of the box by Oracle9i Application Server, should further requirements arise then it is possible to implement SSL through the software or (as recommended above) through an LBR

High Availability (HA)

This architecture provides no HA capacity whatsoever. ACME Small Co. outlined their requirements for HA as a 'nice to have'. If this proves to not be the case, then HA can be provided through the realms of Cold Failover Clustering (CFC), more information on this can be obtained from OTN. Low levels of redundancy will be provided for the mid-tier purely by the existence of two mid-tier machines, within these two machines it will be possible to configure them to operate two OC4J_Portal instances thereby giving servlet execution redundancy on each machine. There is no redundancy built in to the infrastructure tier.

Assumptions

• The assumptions for performance are based upon using suitable caching models, preferably full page wherever possible, failing that PMD and Portlet caching
• Low data volumes for the content
• No increase in user request rates
• Low login rates (i.e. no spikes)
• Suitable network infrastructure with good/reasonable latency (<20ms) for roundtrips between the users browser and the mid-tier
• Reasonable development/request  mix - i.e 20% of page operations are for page development and maintenance, 80% of operations are simple page request for predominantly cached content
• The infrastructure DB will not be used for storing customer application data other than that generated by the Portal interface.

Options

The following suggestions are provided as indicators for ACME Small Co. to consider in the event of a projected expansion

• Consider running more than one OC4J_Portal instance in the mid-tier for redundancy
• All the infrastructure schema's are in one machine, currently the only supported method for infrastructure failover is through cold failover. It is possible to install the Portal and OID schema's into a RAC node thereby offering a more dynamic form of HA than that provided by CFC
• An increase in login load would probably necessitate the inclusion of a separate login machine and the stripping out of the LDAP processes and OID & SSO schemas from the infrastructure.
• Should document storage requirements increase consider moving the portal repository or documents table to another machine or set of spindles

Summary

This recommendation document is designed to serve as an indication of a suitable implementation architecture. Implementation may be possible with an architecture that differs from the one recommended, and with less or more hardware. The most reliable method for sizing a suitable implementation architecture is to run a proof of concept or pilot prior to full implementation. This will allow the implementation team to assess the likely success of the suggested implementation architecture and adjust the specifications accordingly if the need to do so is demonstrated by the results.