Performance testing
To find out the performance of your system in the first place, you will have to run a performance test to get an idea of how many users will be able to access the site at the same time without noteworthy delays. Even at a later time, load tests are most helpful to find out how much performance was gained by a specific tuning measure. After each tuning step, the load test has to be repeated (10-15 iterations of it are not uncommon), until the system is tuned for optimal performance. For performance assessment and tuning, the following test requirements can be stated:
That implies that you have to create a model of your expected real-world, production level workload, based on your experience and knowledge of your clients' behavior. Using this representative model in combination with a stress test tool, you will create as many testcases as needed, and combine them into a testsuite that simulates the desired user behavior and performs the necessary interactions with your site during a load test. In some cases, when no good estimate of such a model can be given, even a crude approximation is better than performing no load test at all, and it can always be refined for future test cycles.
Tuning without the ability to perform repeatable tests is very hard, because the lack of comparable performance data. To be repeatable, it is necessary to restore the initial system state after each test iteration. Usually persistent application or transaction data is stored in databases or backend systems, so that implies the following requirement:
A second, staging database and or backend system has to be used for testing purposes. Changes to the data on that system will not have consequences in the real world: meaning, the placing of a thousand orders in an online shop during load testing will not activate the order fulfillment process in the backend.
The goal is to find the site's saturation point. First, the system has to be driven even over the point where performance begins to degrade. This is commonly referred to as drawing the throughput curve (see Figure 19-3).
Start a series of tests to plot the throughput curve. Begin testing with wide open server queues (pools) to allow maximum concurrency in your system. Record the throughput (average requests per second) and the response time (average time for requests), increasing the concurrent user load after each test. You will find the system's saturation point in the diagram where the throughput becomes constant (the maximum throughput point is reached), but response time begins to grow proportionally with the user load.
Refer to 19.4.4, Adjusting WAS system queues for more information on the queuing network and Determining optimum queue sizes for detailed explanation of the steps on drawing the throughput curve.
Note Here the goal is to drive CPU utilization to nearly 100 percent. If you cannot reach that state with opened up queues, there is most likely a bottleneck in your application, in your network connection, some hard limit on a resource or possibly any other external component you did not modify. |
Figure 19-3 How to find the optimum load level for a system: the saturation point
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.