Analysis of the test results and system tuning is done in between each of the experiments. The experiment is designed
to collect the data needed for tuning the subsystem or balancing the load across a cluster of servers. By moving from
tuning a single application server to driving a cluster of application servers, you also introduce issues with pooling
of connection to back-end database servers. Normal programming defaults will have multiple connections per virtual user
session to the back-end database. This proves to be a significant and often repeated tuning exercise to redesign the
application to pool these connections across multiple user sessions. Sizing the pool of connections to meet the need of
the expected load of simultaneous outstanding requests to the database is something that must be done while driving one
or more of the application servers at full load.
It is important when planning your performance testing project to allow time in the schedule for sizing the application
server, testing the load balancing across the cluster, tuning the database connection pool and maybe even some database
table indices or optimizing certain application segments making multiple database queries in sequence to satisfy a user
request. Leave time for possible work on heap fragmentation or memory leak issues in the application server testing if
the application has not been stress tested before or if this is a significant re-write of the application. Once these
preliminary activities have been scheduled then you can add in three to five full load tests to get your final system
capacity measurements. Also if a multiple day soak test for system availability is requested, add schedule time for at
least two or three attempts at performing this test with at least one day in between to analyze the results and modify
the application in preparation for the next test run.
|