Based on the information received from ACME Large Co. the following is a
reasonable initial estimate of the hardware required to service the usage requirements
specified. A proof of concept is vigorously recommended to further affirm the
estimation supplied here.
ACME Large Co. have stated that their user community
will be approximately 3,000 'concurrent' users, however the definition of
concurrency in the case of a portal is not actually related to users, the
important load factors are the page request rate and
login rate. ACME Large Co. have indicated that they expect 259,000,000 page
'hits' per month. Assuming these are actual unique page requests and not
iterative hits for item content on a page (e.g. images, JS libs etc), then this
equates to an actual page hit rate (assuming a 30 day month) of 100 reqs/sec.
In terms of sizing Portal applications there is a line drawn between the term
'hits' and 'page requests'. A Page Request is considered to be a unique request
for a portal page, that request will result in one or many subsequent requests
from the PPE and browser for snippets of content or 'hits'. On average, one page
request can result in approx thirty 'hits' for images, JS libraries etc.
In sizing this solution, the initial figure of 259,000,000 'hits' was taken
to be a literal 'page request' translation, so in theory, this architecture
should support 100 reqs/sec or 3000 hits/sec or 7,776,000,000 hits/month. Had
the initial figure of 259,000,000 been interpreted as 'hits' then by a reduction
factor of thirty less hardware would have been required.
If we assume that
a site may have 300,000 registered users
of those 300,000 users 1% are making page requests at any one time
of the 3000 requestors each one clicks twice every 60 seconds
this equates to ~100 page requests per second
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 a Linux based solution.
Component
Description
CPU
Memory
O/S
A
Load Balancing Router
Not Applicable
B
2 * SSO
4 x 1.4GHz Intel
8Gb
Redhat Adv Svr 2.1
C
8 * Web Cache
2 x 1.4GHz Intel
4Gb
Redhat Adv Svr 2.1
D
4 *
Middle-Tier
4 x 3GHz Intel
12Gb
Redhat Adv Svr 2.1
E
2 * Identity Management
4 x 2GHz Intel
12Gb
Redhat Adv Svr 2.1
F
2 * Portal Repository
4 x 2GHz Intel
8Gb
Redhat Adv Svr 2.1
G
Shared Disk
N/A
N/A
N/A
Diagram Definitions
Component 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). 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. 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.
Component B
These machines will run the EM, SSO repository and SSO HTTPD
listener. The machines will be configured using the Redhat Cluster Manager server and
will act as a cold failover cluster
Suggested Vendor Example = Dell 1650 RackMount
Component C
These machines will run the OracleAS Web Cache They will be configured
as part of a Web Cache cluster.
Suggested Vendor Example = Dell 1650 RackMount
Component D
These machines will run the Oracle HTTP
Server components including OC4J_Portal and mod_plsql. They will be configured
to run 2 instances of OC4J_Portal providing rudimentary failover within each
machine
Suggested Vendor Example = Dell 2650 RackMount
Component E
These machines will be the identity management component of
the implementation. Components on this machine will include the LDAP processes and OID schemas.
The machines will be configured using the Redhat Cluster Manager server and
will act as a cold failover cluster with OID DIP Synch between the Primary and
the Backup
Suggested Vendor Example = Dell 6650 RackMount
Component F
These machines will be the portal repository component of
the implementation. Components on this machine will include the portal repository installed in an Oracle
9.2 RAC enabled DB.
Suggested Vendor Example = Dell 6650 RackMount
Component E
Network attached storage, or SCSI shared disk for the cluster.
This architecture provides 25% growth beyond the original content capacity expressed by
ACME Large 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.
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)
HA is provided through the realms of Cold Failover Clustering
(CFC), Oracle Real Application Clusters and OID DIP Synch, more information on this can be obtained from
OTN and
Redhat. Cache tier redundancy is provided by the implementation of web cache
clustering. As no session routing is required to the OC4J machines middle tier
redundancy is not required on a machine to machine basis, however low levels of
redundancy will be provided within each mid-tier machine purely by
the operation of two OC4J_Portal instances on each machine, thereby giving servlet execution redundancy on each machine.
Assumptions
The assumptions for performance are based upon using suitable caching models,
preferably full page wherever possible, failing that PMD and Portlet caching
High data volumes for the content
Contingency of 25% for an increase in login rates
Contingency of 50% increase in login rates
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.
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.
Bookmark
