Understanding load testing
Load testing is a way to test your website or application that allows you to measure the performance and scalability of your website/application under both normal and anticipated peak load conditions. Load testing can be used to determine how many concurrent users can access your site/application with optimal speed for your end users.
It's important to load test your website or application because load testing can help you identify load-related issues that may cause crashes, performance degradation, and system failures.
Save yourself the embarrassment of downtime
With load testing, you can figure out where load-related problems are happening in your server stack, allowing you to fix them before your service gets famous!
When load testing is done
Load tests are usually done when you launch your site to the public, if load testing isn't completed before this time, load-related issues may arise after load tests begin.
Load tests can be done on both desktop and mobile websites/applications because load testing is about website/application performance and scalability.
The benefits of load testing
Load testing helps you identify load-related issues in your server stack, which can result in crashes, performance degradation, and system failures. By load testing your site/application before launch, load-related problems are much less likely to happen.
Load tests are particularly useful if load testing was not completed before launch because load tests help pinpoint load-related issues that load tests would have revealed before the site/application was public.
Load testing is also beneficial because load tests help you identify load-related issues in your server stack, which helps make load testing more efficient and less costly.
Testing web applications
Testing a web application is very different from testing a web server. With an application you need to ensure you test the full stack, including the "heaviest" workloads. By examples these can include:
- Logging users in
- Running searches
- CRUD operations, especially Updates or Creates
These operations are interactive, dynamic content. They typically are generated by a language like PHP, and often require a SQL database interaction. These are the common bottlenecks in a modern web application.
You want to ensure your load testing attacks all the critical components of your application. Typically, this is three things:
- Dynamic content (pages, user profiles, etC)
- Database operations
In developing this strategy you'll want to determine the average wait time of a user of your service. Typically, a user waits on average between 5 and 9 seconds between webpages and that's what you'll want to simulate.
Testing web servers
Server load testing is very different, and has to do with raw requests per second from the web server itself, e.g. Nginx, Apache, etc.
When you are testing the requests per second and throughput capacity of your webservers you want to eliminate external factors, such as:
- Database queries
- Dynamic content
- External services
You want to focus on testing the raw requests per second your webserver delivers. Break your approach up into a couple of steps. Our advice is to follow a testing path like the below:
- Request a small static file, like /robots.txt
- Request a larger image
- Optionally request a dynamic (PHP, etc) page.
We advise you run these tests separately when testing a web server, so you can easily compare the difference in throughput as you change file size, content type, etc.
Your test will give you a large amount of data and graphs to look at, but, there are several important metrics to check first:
- The average response time. This is the time it takes for a user to load a page.
- P95 and P99 response times. This is the time it took (as above) but for the lowest 1% and 5% of user requests.
- Error rates. It's very common for overloaded apps to generate 5xx errors or time out.
- Your overall graph which will show you requests, users, response time and error rates.
The P95 time is an excellent gauge for how your app is scaling. If the bottom 5% of requests are slow or timing out you have problems!
Armed with this information you can then dig further into the report.