Capacity Planning
|
 |
 |
|
 |
 |
Determining Hardware Capacity Requirements
The following sections provide information on how to determine your server hardware capacity requirements.
- Assessing Your Application Performance Objectives
- Calculating Hardware Requirements
- Guidelines for Calculating Hardware Requirements
- Best Practices When Calculating Hardware Requirements
- Capacity Planning Guide FAQs
Assessing Your Application Performance Objectives
At this stage in capacity planning, you gather information about the level of activity expected on your server, the anticipated number of users, the number of requests, acceptable response time, and preferred hardware configuration. Capacity planning for server hardware should focus on maximum performance requirements and set measurable objectives for capacity.
For your application, take the information that you derive from Examining Results from the Baseline Applications, to see how your application differs from one of the baseline applications. For example, if you are using the HTTPS protocol for a business application similar to MedRec, you should examine the metrics provided for the heavy MedRec application. Perform the same logical process for all of the factors listed in Capacity Planning Factors.
The numbers that you calculate from using one of our sample applications are of course just a rough approximation of what you may see with your application. There is no substitute for benchmarking with the actual production application using production hardware. In particular, your application may reveal subtle contention or other issues not captured by our test applications.
Calculating Hardware Requirements
To calculate hardware capacity requirements:
- Evaluate the complexity of your application, comparing it to one or more of the applications described in Examining Results from the Baseline Applications. The example in Guidelines for Calculating Hardware Requirements identifies this value as the Complexity Factor. If your application is about as complex as one of the baselines, your Complexity Factor = 1.
- Consider what throughput is required for your application. In the example, this is called the Required TPS (transactions per second).
- Take the preferred hardware TPS value from the appropriate table. The example in Guidelines for Calculating Hardware Requirements identifies this value as the Reference TPS.
Guidelines for Calculating Hardware Requirements
The number of computers required is calculated as follows:
Number of boxes = (Required TPS) / (Reference TPS / Complexity Factor)
For example, if your assessment shows:
- Your application is twice as complex as the Light MedRec application; the Complexity Factor = 2.
- The requirement is for a 400 TPS; the Required TPS = 400.
- The preferred hardware configuration is Windows 2000 using 4x700 MHz processors.
- The Reference TPS is 205, from Table 2-3, configuration number lmW1.
The number of boxes required is approximately equal to:
400/(205/2) = 400/102.5 = next whole number, 3.90 rounded up = 4 boxes.
Always test the capacity of your system before relying on it for production deployments.
Best Practices When Calculating Hardware Requirements
BEA recommends several best practices related to capacity planning.
- Tune and optimize your application. During the testing process, plan to take steps to optimize the application you will be running on WebLogic Server. See BEA WebLogic Server Performance and Tuning.
- Be conservative when making your capacity estimates. Plan for peak loads that your application might experience. If absolute reliability is preferable to hardware cost savings, increase your estimates.
- Consider future growth requirements. WebLogic Server is extensible. Your implementation might grow over time, as more and bigger clients are added.
- Stress test your application under real-world conditions. Prototype software and tools are available such as LoadRunner (http://www-heva.mercuryinteractive.com) and eLoad(R) (http://www.empirix.com). Some hardware vendors and independent third-party companies offer test laboratories where you can test the hardware on which you plan to deploy.
Capacity Planning Guide FAQs
This section contains some frequently asked questions and answers.
Mainframes and Other Types of Hardware
What about mainframes or other types of hardware? How do I determine capacity planning information for those systems? Consider the mainframe as a multiple of many individual PCs.
Heterogeneous Client Types
What should I assume about heterogeneous client types? How about programmatic along with HTTP clients? When in doubt, assume the worst. In this case, assume that 100% of the clients will be HTTP clients and develop your capacity planning numbers appropriately.
Improving Application Performance
How do I get my application to run faster? Tune WebLogic Server first, using the BEA WebLogic Server Performance and Tuning, included in BEA Systems documentation. Second, consider using a tuning tool such as jProbe from sitraka at http://www.sitraka.com to find bottlenecks in the code. Also, check the latest in the WebLogic Server documentation and customer support FAQs to see up-to-date application tuning and design guides.
Determining Memory Requirements
How do I determine how much memory I need? BEA Systems recommends that you install a minimum of 256 MB of memory for each machine running WebLogic Server that will be handling more than minimal capacity. If you are expecting a very heavy load, BEA Systems recommends that you increase your memory substantially.
A WebLogic Server deployment tracks session objects in memory, either to RAM or swapping to disk. There must be sufficient RAM/disk to store all the session objects. This RAM is accessible to Java through the Java heap.
For more information on memory requirements, see BEA WebLogic Server Performance and Tuning.
Allowing for Think Time
"Think time" is the time spent by a user between transactions or surfing from one page to another. The BEA capacity planning benchmarks do not account for think time. Rather, the benchmarks send out each subsequent request as soon as the previous one finishes. However, in a real world scenario, a user typically spends a little time between pages.
Given an estimated think time (ETT) in seconds and anticipated transactions per second (TPS) there is a general calculation you can make to estimate the number of concurrent users your system can support:
