Maximum number of contemporary users

Question

Hi Everybody,
in my company we're planning for a new "Portal & Wireless" installation, and we need to know how many contemporary users can be served by the system. We have a three-tier architecture, with two different servers for the middle-tier (IBM x342, with 2 intel Pentium III 1400 MHz processors and 2GBs Ram memory)load-balanced by a Radware machine, and with the infrastructure (DB, SSO & OID) installed on a 4 Ultra Spark 400 MHz processors system (4GBs Ram). Does someone know any sort of algorithm to get the maximum number of contemporary user? Otherwise, which way can I estimate that value? Do you know any 'enlightening' document about this issue?
Thanx!

Answer 1

There is no easy answer to this question. You may find this document interesting.
How your hardware performs will vary widely based upon what you run on it.
Estimating anything can be a complex and error-prone process, that's why it's an 'estimation' not a 'calculation'.
Primarily there are three approaches to sizing a portal implementation, these can be identified as:
Algorithm or Calculation based
An algorithm or process that accepts inputs from the customer (e.g. user count, page count, hits, latency, doc size etc) and attempts to deliver a processing requirement is probably the most commonly accepted tool for delivering sizing estimations.
Unfortunately this approach is also the most inaccurate.
When considering a logical n-tier enterprise class portal implementation the number of variables involved in delivering a calculation that even approaches a realistic sizing response would require input values numbering in excess of one hundred, and calculations so complex and sensitive that providing an input value plus or minus 1% of the correct value would result in wildly inaccurate results.
The other approach to calculation based solutions would be to simplify the calculation to the point where it was simple to understand and simple to use. Unfortunately the sizing results delivered from this approach would also be wildly inaccurate.
Size-by-Example based
A size-by-example (SBE) approach requires a set of known samples that may be used as data-points along the thermometer of system size. The more examples available for SBE the more accurate the intended implementation will be. Asking a customer how many users they will have, what those usage patterns are likely to be and what type of content they intend to deploy on the portal are all questions that they should be able to answer. Asking them the likely cache-hit-ratio for a portlet is probably something they won't be able to answer unless you're asking the right people. Normally in a pre-sales situation the customer will not know the answers to questions like that. Those are the types of questions that would be required for the algorithm approach.
Oracle has the ability to deliver targeted SBE sizing solutions for our prospective portal customers through reference implementation documents that outline both our internal deployments and customer's external deployments.
By using these real world examples both customers and Oracle can be assured that the configurations being proposed have been implemented before and will provide the performance and functionality unique to the proposed implementation.
Proof of Concept based
A proof of concept (POC) or pilot based approach offers the most accurate sizing data of all three approaches.
A POC allows the customer to do the following :
Test their portal implementation design
Test their chosen hardware platform
Test their caching strategy
Simulate projected load
Validate design assumptions
Validate Oracle9iAS Portal
Provide iterative feedback for their implementation team
Adjust or validate the implementation decisions made prior to the POC
There is, however, two downsides to a POC based approach, namely time and money.
Running a POC requires the customer to have manpower, hardware and the time available to implement the solution, validate the solution, iterate changes and re-test and finally analyze the POC findings.
A POC is always the best and recommended approach for any sizing exercise, it will deliver results that are accurate for the unique implementation of the specific customer, and that are as close to deploying the real live solution as possible but without the capital outlay on hardware and project resources.
Hope this helps
Jason Pepper