The purpose of a load test is to measure the site’s performance while handling simulated user activity. The Load test produces metrics that show the speed and scalability of a site.

The Load Test is about identifying three things:

•             The speed with which a site will respond from the end-user’s perspective under load.

•             The number of simultaneous visitors a site can handle.

•             The specific bottlenecks or infrastructure limitations that lead to poor website performance.

Why Load Test?

The short answer is Money. At time, eCommerce portal weaknesses get discovered when a flood of real visitors arrive – in other words, when it’s too late. Sites that slow down under heavy load will lose customers. Fast and scalable sites make more money.

Companies lose millions: Amazon says that for every 0.1 second of delay they lose 1% of their sales. Based on 2012 revenue of $13B, a 0.1 second delay costs them $130 million.

Test runs on a major online retailer show that they would lose $100,000 every hour with a 25% traffic spike over optimal capacity.

Benefits

User Experience

If a website’s response time is poor, it alone will ruin a user’s experience. In fact, it will drive users to competition. Reducing response time improves the user experience of websites. Websites realize that improved performance leads to an increase in traffic and conversion rate.

Faster Load Times

According to a survey of 160 organizations by Aberdeen Group, a 1 second delay in load time results in 7% less conversions. For a company earning

$100,000 a day, that would result in a loss of $2.5 million in sales each year. These statistics gives us an idea of the losses due to poor website performance, and the importance of a great user experience

Plan Load Tests

Load testing should not be difficult. One needs to follow some of the best practices. Actionable results come from intricate planning. Unrealistic traffic will lead to inaccurate performance metrics.

Collect Traffic Information and User Behavioural Data.

To make virtual users more realistic, we need information about the people that visit the website. This information can come fromPage Tagging (Google Analytics or similar) or Log Files. Page tagging is an easy way to collect user behaviour information. Google Analytics is one of the most popular page tagging services available.

Log files can show useful traffic information such as

–          Pages hit

–          Sequence of user activity

–          Files transferred

–          IP addresses of requestors

–          Volume in  a certain time window

Establish User Profiles.

Once we have all the information about users, the next step is to determine how real users interact with the site. We can then develop virtual user profiles to simulate their behaviour. The more profiles we identify and put into the test design, the more realistic the load tests will be. The most important aspect to consider is that each virtual user should represent the load of a real user.

For each user type identified, collect the following information:

–          Steps – What actions users take while using the website? Are they logging in?

–          Time per Page – On average, how much time is this user type spending on each page?

–          Time per Session – On average, how long does this type of user spend on the site?

–          Pages per Session – On average, how many pages do they visit in a single session?

Set Test Goals.

What are the benchmarks that the eCommerce website should meet? Set the expected results, and even a range for results.

–          Load:

• Concurrent users
• Requests per second
• Throughput

–          Response:

• Average response times
• Slowest responses
• Errors

Set the Budget.

It is important to budget testing and optimization expenses. Often, a web project does NOT budget for load testing or performance enhancement. Consider the budget (or lack thereof) before shopping for a tool.

How to Build Good Load Tests:

Test Scenarios:

We need test scenarios that represent realistic user activity. We need to configure user types, the behaviour of each user, and the relative weighting of those users to get the correct mix of traffic.

Different Steps for Users of the Same Type:

It is preferable to have virtual users within a type to take different actions. This is more realistic than having all users of a specific type visiting exactly the same pages in the same order.

Testing From Data Sets:

It is necessary to have each authenticated user with a different set of credentials. This represents usual and customary traffic, and it ensures accurate consumption of system resources.

Testing Target Environment:

Having production environment as the target should remove any doubts on system performance. There is only one way to know for sure. I recommend that to test on production system during off-peak hours. Look at traffic data to find the time when the website is least active. It’s also advisable to watch the live performance data so that we can kill the load test before the site crashes.

How to Run Load Tests:

Here are some variables used to run a test:

Scheduling

Many of our clients prefer load tests at off-hours when there is minimal traffic. 2AM seems to be popular. When testing against a staging environment, timing is less important.

Start Small

When starting a series of load tests, always start at an amount of load that the website can handle. Then we can gradually increase it. This determines the load at which the website response times increase.

Rate of Load Increase

The rate at which the user numbers increase will affect the website’s performance. So be aware of subtle differences in load patterns during testing.

Duration of Load

A web application must also be able to withstand heavy loads for longer periods. Long periods of heavy load can reveal problems that remain hidden during shorter load tests.

How to Analyse Test Results

The load test measurements calculate metrics such as Average Response Times and Throughput. Performance metrics identify responsiveness of the whole system from the users’ perspective.

A responsive site with no errors during periods of heavy traffic is achieving its performance goals. There is an upper limit of load where all sites fail. When the web server returns errors (e.g. status code 503) or timeout, we can conclude the site has exceeded capacity.

Conclusion:

Load testing may be simple in theory, but it can be complex to execute well. If we have planned thoroughly, built realistic test scenarios, and ramped-up virtual users correctly, then there is a high probability of producing actionable test results. Results will identify limitations in the web architecture.