As a core definition, load testing is the practice of sending simulated traffic (typically HTTP) to a web server and measuring the capability of that server to process the traffic.
We can measure this capability, or performance, in a variety of ways:
- Ensuring that the server will respond in a timely manner, thus providing a satisfactory end-user experience.
- Assessing the server’s resource utilisation through metrics such as CPU, memory etc.
- Identifying potential performance bottlenecks, such as a page that is particularly slow to load or an API that is slow to respond.
- Counting the number and different types of errors that occur in the system when under varying levels of load.
- Determining how many users the system can comfortably support simultaneously.
A load test is performed by executing specialist load-testing software on one or more computers. This software generates and transmits a large number of requests to a web server, where the target application is running.
The load-testing software then measures the time taken for the server to respond to the requests and counts the number of errors that occur. Separate monitoring software works in conjunction to instrument the webserver and assess resource utilisation.
Some distinct types of load test that can be run are:
- Capacity test
Increase the load gradually on the system until you find the point that system degradation begins to occur.
- Soak test
Run a constant throughput to the system for an extended period (e.g. 24 hours), looking to identify issues such as memory leaks.
- Stress test
Assess how your application behaves when it receives a big spike in traffic, and determine how the system behaves and recovers after this spike subsides.
Whatever type of load test or tests you eventually decide to execute, there are a few common terms and concepts that it is good to be aware of:
- System Throughput
This is a measure of how many transactions, or requests, the application can process over a specific period of time. Throughput is typically reported as requests per second. It gives a clear indication of the rate of traffic that the system will be able to handle.
- Response Time
How fast will the server respond when it is sent a request from the client? The response time is measured on the client side that sent the request, and is the time between the request being sent and the full response received from the server. This value is typically measured in milliseconds(ms), and is sometimes referred to as latency.
Response times that are collected from performance testing are often grouped into percentiles. Percentiles are typically recorded at various ranges such as the 50th, 70th and 90th percentile. For example, if your 70th percentile response time is 200ms, then 70% of transactions took 200ms or less to complete. Percentiles give a more accurate feel for what your end users will experience in performance, as compared to average response time which can vary greatly to the end user.
The load testing exercise that you perform can help you to answer important questions about your project and web application, such as:
- Will our application run efficiently and as expected once we release it into production?
- Is the performance of the application satisfactory to provide a great user experience?
- Do we need to adjust the backend hardware of our system in order to support the application sufficiently?
- Can the designated hardware handle the expected load?
- Are there particular pages or areas of the application that can be tweaked, improved or modified?
Without conducting proper and effective load testing, it is difficult to confidently answer any of the above questions. Taking the risk on deploying an application into production that has not been sufficiently tested for performance introduces an undesirable level of risk. Better to mitigate that risk beforehand with robust and thorough load testing.
Learn more about Gatling, the best developer tool to load test your applications, at gatling.io
The Gatling team