The first step in designing a Web site load test is to measure as accurately as possible the current load levels.
The best way to capture the nature of Web site load is to identify and track, [e.g. using a log analyser] a set of key user session variables that are applicable and relevant to the Web site traffic.
Some of the variables that could be tracked include:
- the length of the session (measured in pages)
- the duration of the session (measured in minutes and seconds)
- the type of pages that were visited during the session (e.g., home page, product information page, credit card information page etc.)
- the typical/most popular ‘flow’ or path through the website
- the % of ‘browse’ vs. ‘purchase’ sessions
- the % type of users (new user vs. returning registered user)
Measure how many people visit the site per week/month or day. Then break down these current traffic patterns into one-hour time slices, and identify the peak-hours (i.e. if you get lots of traffic during lunch time etc.), and the numbers of users during those peak hours. This information can then be used to estimate the number of concurrent users on your site.
Although the site may be handling x number of users per day, only a small percentage of these users would be hitting your site at the same time. For example, if you have 3000 unique users hitting your site on one day, all 3000 are not going to be using the site between 11.01 and 11.05 am.
So, once we have identified the peak hour, divide this hour into 5 or 10 minute slices [one should use your own judgement here, based on the length of the average user session] to get the number of concurrent users for that time slice.
Once we have identified the current load levels, the next step is to understand as accurately and as objectively as possible the nature of the load that must be generated during the testing.
Using the current usage figures, estimate how many people will visit the site per week/month or day. Then divide that number to attain realistic peak-hour scenarios.
It is important to understand the volume patterns, and to determine what load levels your web site might be subjected to (and must therefore be tested for).
There are four key variables that must be understood in order to estimate target load levels:
- how the overall amount of traffic to your Web site is expected to grow
- the peak load level which might occur within the overall traffic
- how quickly the number of users might ramp up to that peak load level
- how long that peak load level is expected to last
Once you have an estimate of overall traffic growth, you’ll need to estimate the peak level you might expect within that overall volume.
Estimating Test Duration
The duration of the peak is also very important-a Web site that may deal very well with a peak level for five or ten minutes may crumble if that same load level is sustained longer than that. You should use the length of the average user session as a base for determining the load test duration.
As mentioned earlier, Although your site may be handling x number of users per day, only a small percentage of these users would be hitting your site at the same time.
Therefore, when preparing your load test scenario, you should take into account the fact that users will hit the website at different times, and that during your peak hour the number of concurrent users will likely gradually build up to reach the peak number of users, before tailing off as the peak hour comes to a close.
The rate at which the number of users builds up, the "Ramp-up Rate" should be factored into the load test scenarios (i.e. you should not just jump to the maximum value, but increase in a series of steps).
The information gathered during the analysis of the current traffic is used to create the scenarios that are to be used to load test the web site.
The identified scenarios aim to accurately emulate the behavior of real users navigating through the Web site.
for example, a seven-page session that results in a purchase is going to create more load on the Web site than a seven-page session that involves only browsing. A browsing session might only involve the serving of static pages, while a purchase session will involve a number of elements, including the inventory database, the customer database, a credit card transaction with verification going through a third-party system, and a notification email. A single purchase session might put as much load on some of the system’s resources as twenty browsing sessions.
Similar reasoning may apply to purchases from new vs. returning users. A new user purchase might involve a significant amount of account setup and verification —something existing users may not require. The database load created by a single new user purchase may equal that of five purchases by existing users, so you should differentiate the two types of purchases.
Next, program your load test tool to run each scenario with the number of types of users concurrently playing back to give you a the load scenario.
The key elements of a load test design are:
- test objective
- pass/fail criteria
- script description
- scenario description
Load Test Objective
The objective of this load test is to determine if the Web site, as currently configured, will be able to handle the X number of sessions/hr peak load level anticipated. If the system fails to scale as anticipated, the results will be analysed to identify the bottlenecks.
The load test will be considered a success if the Web site will handle the target load of X number of sessions/hr while maintaining the pre-defined average page response times (if applicable). The page response time will be measured and will represent the elapsed time between a page request and the time the last byte is received.