Excellence in Web Performance
top
Products
spacer

Web Load Testing Basics

This section deals with the general questions about Web Load Testing: The whys, and whens and hows of it all.

If you’re already familiar with load testing and want to understand the Apica LoadTest™ product better,  please go to the Load Test – features section. 

Summary

  • What is load testing?
  • Why should I be load testing? 
  • Isn’t function testing enough?
  • The monkey and the test tube
  • When should I be load testing?
  • Understanding the load curve
  • Load testing – It’s only rocket science
spacer
Request callback

Let us contact you for an assessment of your Load capacity and Load testing needs.

Yes - Contact Me 
Yes - Contact Me
A load test engineer will contact you within 24 hours

spacer
Result examples

Analyze load times

Graf
Click here for larger image

Find thresholds

 
Click here for larger image

spacer

1. What is Web Load testing?

Web load testing or stress testing, is the testing of (web) applications by simulating a certain (large) number of users.

The objective of load testing is threefold:
1. Finding out what your maximum load limit is – How many concurrent users can you handle with sustained response times?
2. What is the behavior of the application close to the capacity limit?
3. Identifying bottlenecks - Which are the components that limit the load capacity?

The load can be generated in several different ways. The hard part is not really to generate the load, but to do it in a controlled way so that you are able to monitor the application as load increases and extract test data which can be analyzed. There’s really no point in knowing your capacity limit if you don’t know why, and what is creating that limit.
 

2. Why should I be load testing?

There are two main arguments for load testing:

  1. Don’t drive blindfolded. Not knowing your limit is risky business. If you don’t know whether your (web) application is on par with your business objectives, you’re in a bad spot.

    All organizations are exposed to traffic peaks in one way or another, wanted as well as unwanted. There are seasonal patterns, sudden media hypes, force majeure events, hacker attacks and much more. So if you don’t know how much margin you have before you reach your limit, you could be in trouble.

     

  2. Avoid unnecessary infrastructure investments. Through the years, we have seen many examples of organizations that compensate for the lack of a web performance strategy by just adding more and more hardware. Prices are coming down, but capacity demands go up even more with such things as video.

    The problem is that if the setup isn’t sound from the beginning you will sooner or later “hit the wall”, where it will be almost impossible to increase your maximum load capacity without “starting from square one”.

    So instead of adding more hardware, you should use a load test to identify your weak points, remove them and increase your capacity without costly infrastructure investments.

3. Isn’t function testing enough?

Apica’s experience shows that many web projects fail to verify the stability of web sites during peak load. Despite exhaustive testing of functional requirements, Projects still fail to launch stable performing web applications on time. Why is that so?  

Web development projects are tested against hundreds or perhaps thousands of use cases, ensuring that all functional and non-functional requirements are met. ISPs and web hosting companies are subjected to strict SLA agreements.
Nevertheless, project launch often means disappointment in terms of performance:
- “Why is the site so slow?“ or
- “Why does the site go down at peak hours?“
This marks the start of a massive “blame game“ between ISP, hosting company, platform provider, developer and application owner.

A new and structured approach to Web performance management means:

  • Bottlenecks in the application and infrastructure are identified before project launch.
  • Capacity planning is based on the performance of the very production site(s), resulting in optimal infrastructure versus application and load scenarios.

4. The monkey and the test tube

Sometimes we joke and say that not doing any load testing is like taking a medicine which has been tested on one single chimpanzee. That just sounds plain stupid, doesn’t it?

This is how it goes:
When you do function testing you test with one single simultaneous user in the test environment. The test environment is normally a “very close” copy of the production environment. Just like the chimpanzee, which has 98% of the DNA of a human. So testing with one user on the test environment is like testing a new drug on one chimpanzee. But new drugs are not released until they have been tested clinically on thousands of real humans.

Therefore you should be testing your business critical web applications with thousands of simultaneous users in the production environment.


5. When should I be load testing?

It has become quite common that web applications are stress tested before the launch of a new site or service.

As we see it, web load testing should be an integrated part of your development, deployment and operations methodology. In other words, part of your IT DNA. 

Test before every major release and use the Apica WebPerformance monitoring service to make sure your performance remains stable between releases.


6. Understanding the load curve

The "load curve” shows the typical variation in response times as the number of users increase.

A “healthy “ web application typically shows a very small increase in the response time as the number of users increase at low levels. This shows that the application and infrastructure are well balanced and can absorb load without any larger increase in response times. At a certain point, which we call the “knee” in the load curve, response times start increasing.

As the response times increase and eventually become infinite, the “throughput”, (ie the data sent from the server to the users), decreases, which means that the user experience becomes an endless wait for the hourglass.

In the worst case the application will stop responding, response time is infinite and throughput zero. This is a crashed site.

Finally, when load is reduced, an important question is if the application will be able to return to a stable state or if it has to be restarted.

Thorough analysis of the load test data might also reveal weaknesses well before critical loads are reached. In such cases you might detect “spikes” in the load curve which means that your application and/or infrastructure are not stable in terms of web performance.
 

7. Load testing – It’s only rocket science

We have three criteria for successful load testing:

A load test should be  

  1. Realistic - Have a close resemblance to actual user behaviour.
  2. Scalable – Possible to ramp up load in a controlled fashion.
  3. Analyzable - Data should give a detailed view, not only of the load capacity, but also of the behaviour of the application throughout the load test.

Performing a realistic, scalable and analyzable load test includes many critical steps and components.

...also of the behavior of the application… ...First, there is the software that generates and controls the load. Second, there is the software that records and visualizes the test data. And last but definitely not least, you need a well-designed infrastructure with load servers at strategic points in the global Internet network structure.

Be sure to choose a partner with proven experience in web performance management before you start your load testing. 

bottom
120105