WebSphere Application Server V8.5 Administration and Configuration Guide for the Full Profile

494 WebSphere Application Server V8.5 Administration and Configuration Guide for the Full Profile

14.1 Performance tuning overview

Application architecture, system infrastructure, and the amount of load on the system are

three essential factors that determine the optimum values for the parameters that we

introduce in this chapter. There is no single value for any parameter that will work optimally on

all systems. You need to go through capacity planning, stress test, collect information, and

analyze results to reach a set of optimum values for your system.

To tune for performance, you need to have a performance test system that is identical to your

production system. For the results of the test to be meaningful for the production, the

hardware and software on the test system must be identical to the production.

To measure the success of your tests, generate a workload that meets the following

characteristics:

 Measurable: Use a metric that can be quantified, such as throughput and response time.

 Reproducible: Ensure that the results can be reproduced when the same test is executed

multiple times. Execute tests in the same conditions to define the real impacts of the

tuning changes. Change only one parameter at a time.

 Static: Determine whether the same results can be achieved no matter for how long you

execute the run.

 Representative: Ensure that the workload realistically represents the stress to the system

under normal operating considerations. Execute tests in a production-like environment

with the same infrastructure and the same amount of data.

To determine performance targets, you need a clear understanding of your system

architecture and requirements. Investigate architectural documents, use cases, and functional

and non-functional requirements. With a clear understanding, you can define performance

success criteria.

Define your own performance success criteria. Without a goal or target, you cannot determine

if the performance campaign was successful. You have to avoid non-figured success criteria,

for example, aiming for the “best” performance that you can have. Keep in mind that

performance testing can be endless if you do not have target figures to reach. Each time you

test, you will find a new bottleneck to solve with a new solution. In the end, you cannot

determine whether the test is a success or failure.

Do not attempt to conduct performance tuning on production systems with live load because

there is a high chance that the server will be recycled for the new parameters to take effect.

This recycling process can cause downtime for the production environment.

14.2 Using the queue analogy to tune WebSphere resource

pools

WebSphere Application Server functions similarly to a queuing network, with a group of

interconnected queues that represent various resources. Resource pools are established for

the network, web server, web container, EJB container, Object Request Broker (ORB), data

source, and possibly a connection manager to a custom back-end system. Each of these

resources represents a queue of requests waiting to use that resource. Queues are

load-dependent resources. As such, the average response time of a request depends on the

number of concurrent clients. The tuning of these queues is an essential task to tune for

performance.