All the tools that can help a website or intranet application developer to ensure it won't crash under load.

Why load testing?

In today's complex web application world, developers need to test applications that go beyond simple HTTP-based pages. They need to test Rich Internet Applications (RIAs) that incorporate complex technologies like Oracle Forms.

An application server's default settings for accessing databases, and the default settings of the databases themselves (connection pools, dedicated memory allocation, table indexation...), are not always suited to the application itself and often need to be adjusted. The load test, coupled with the Oracle server monitoring, allows you to tweak these settings and observe any subsequent improvement or deterioration in performance.

The methodology

The following steps are an overview of the methodology that was used:

• 1. Define a realistic scenario.
• 2. Record the scenario.
• 3. Playback the scenario to simulate concurrent users, each time simulating more users.
• 4. When performance is degraded beyond usability, you have reached the maximum number of users.

Define a Realistic Scenario

When you record a scenario that is to be played back, there will be potentially hundreds of simulated users playing that scenario concurrently. It is important that the scenario is representative of the actions of your user population. The scenario should perform the same types of operations as your users this is obvious to most people but also at the same speed your users would.

Often, testers will carefully research what actions their users perform. Satisfied, they will then record a scenario, but record the actions in quick succession, thinking that it's the only the transactions themselves that are important. Equally important is the think time, the time between operations.

The results

Does the test results shows :

• the number of open, system and idle sessions for the database ?
• the number of calls per second to your server ?
• the percentage of calls to the database that did not use a cache ?
• the percentage of SQL requests using indexes ?
• the number of blocks per second for each of the logical accesses ?
• the number of blocks per second for each of the physical accesses ?
• the wait time in seconds for a particular event ?
• the SGA (System Global Area) memory allocated to the various pools and buffers ?

• How many users can the application handle while maintaining an acceptable response time?
• What is the load threshold above which the server begins to generate errors and/or refuse connections?