This chapter is from the book
This chapter is from the book
This chapter is from the book
23.2 Repeatable Performance Scenarios
23.2.1 Test System
In any performance tuning scenario, it is best to have a "controlled environment" such that running the same test multiple times will result in the same (or nearly the same) outcome. In addition, it should be a test system where running tests, recycling servers, modifying configurations, or adding heavy traces does not impact production. This isolates the impact of your changes to the change itself and reduces "noise."
This test system should also be similar to the production system so that it can be used to accurately predict the performance of the production system. Items here would include software levels, access to enterprise information servers (DB2, CICS, IMS, etc.), memory, and so on. The actual CPU resource of a test system is normally smaller than the production system.
23.2.2 Test Tools
There are many excellent test tools that can be used to generate sample browser workloads. These tools are ideal for performance work as the same scripts (same requests, same number of concurrent users, and same wait time) can be run repeatedly. We do not review individual tools available in this document, other than to say that most of them can adequately drive load against your system.
23.2.2.1 Scripts
When using the test tools, it is best to set up test scripts that resemble a particular set of functions in the application. The simpler scripts may yield more predictable behavior and isolate smaller levels of functionality. These are ideal, especially if a problem is occurring. For example, you might want to create a test script for each individual transaction and capture performance data with multiple users executing the same transaction. You might also want to have a test script with multiple users concurrently executing all transactions so you can study the interactions of your transactions
If it is feasible to create a representative workload without making updates to the database, this is an ideal situation. If this is not the case, then the back-end data store needs to be periodically reset.
23.2.2.2 Restoring the Data for Each Test
Resetting the data store in DB2 is the most common requirement. This can be done via various third party tools or simply by unloading and reloading the specified tables. The unload and reload methods run quickly and reset the database to a consistent state before each test. While the unload need only occur once (when the database is in an initial state that is ideal for the test), the reload should run before each test. It is a good idea to also call run RunStats after each reload (can be an added step in the reload job). Resetting other resources is beyond the scope of this chapter.
23.2.3 Simplification of Scenario
It is best to have the simplest possible scenario to re-create any situation on the system. Applications can become complex, including back-end data stores or execution environments, and network infrastructure, including firewalls, and so on. Initial performance testing should include as much of this complexity as is feasible. If a workload does not meet expectations, it is often best to break it down into the simplest component parts feasible. This can isolate the problem component(s), and it makes it easier for any external support to re-create and work on the problem.
TIP
Using test tools placed close to the system under test (SUT), it is often a simple procedure to eliminate firewalls, Web servers, and other network components, thus isolating the work in the J2EE server and the back ends.