Why consider load testing?How do you measure the operating capacity of your software? Will it be able to continue operating as expected under certain load-intensive situations? To answer these questions, there’s a type of test we can use: Load Testing.
What Is Load Testing?As the name implies, load testing is a type of test used to determine the load that a given instance of running software is capable of handling. Just like heavy vehicles such as buses and lorries, which have their own load or weight limits, a software based system also has its limits in terms of number of users, actions, etc., that it can handle concurrently. It is important to know these limitations so that an organization or team of engineers can design solutions according to expected load on their software systems, and where necessary, improve the performance and reliability of the system. This also help the team to be ready if, excuse my french, *beep* hits the fan.
Load testing is a type of non-functional testing as it does not test functionality, but rather stability and performance. As an e-commerce based company, we have a lot of visitors to our website on a daily basis. By running load tests, we can ascertain the number of concurrent users our systems can handle before their performance degrades.
Examples Of Load TestingIn order to run proper load testing, we model what we consider as a load (duh) by looking at patterns of real user behavior. For examples:
- Downloading large files from the website
- Opening up a lot of applications on a computer
- Hitting a server with a lot of users
For our operations, the third point will be the most suitable type of load tests to run.
Choosing A ToolFirst of all, we need to have a proper tool for load testing, either manually or in automated fashion. As load testing involves large volumes of traffic, clients, or users to properly test a system, a manual approach is neither logical or practical as it requires a lot of labor, making it difficult to simulate enough load on a system to truly test it. For automated tools, we can either:
- Build our own
- Use free (open source) solutions
- Pay for enterprise / licensed solutions
For obvious (effort based) reasons, we won’t be building our own tool. Besides, there are a lot of open source tools readily available. As is common with other tool selection, we considered these points when choosing the tool:
- Open source: Yup. Who doesn’t love freebies?
- Multi-platform: Easy to execute on a wide range of systems.
- Programming / Scripting Language(s): Supports popular languages; easy to learn, familiar languages will be a huge advantage in terms of development and support.
- Meaningful report: Generate a quantified and detailed report after running load tests for analysis.
- Support: Good support (from the tool's open source community), available long-term, in case we run into issues.
All things considered, we end up choosing Apache JMeter, an open source tool. It’s not an overstatement to say that JMeter is the most popular open source load testing tool out there. With great community support, being Java-based (meaning that it can run practically anywhere), having a GUI, providing great reports, and even supporting scripting through Groovy for further customizations, this was an obvious choice. The GUI also simplifies many features.
How Do We Do It?Now that we have our tool, it’s time to put it into good use. First, we find out the number of users during our peak period (the point of time where we have a lot of simultaneous users). Considering we are able to handle the number of users without hiccups, we double the numbers for the load test, so we stress test the system for future expected growth. These users are then split into different flows such as purchasing, logging in, resetting passwords, etc. How do we split the numbers? Through rigorous discussions and logical deductions of course! cough cough Google Analytics cough cough.
Now, it’s time to convert these numbers into JMeter. In JMeter, or at least in the GUI, the users are called threads. So, for each flow, we will fill in the number of threads and the ramp-up period of 20 minutes. The ramp-up period is the period in which the users (threads) are spawned in that timeframe. For example, 50 users in the ramp-up period of 10 seconds will spawn 5 users per second. Each user will then complete the configured test flow.
We created a perfect duplicate of our live environment to run the load test. The load tests are executed on this environment and reports are generated. Through the reports, we determine whether our system is capable of handling the users. Live monitoring is also fairly important during load tests to determine the exact bottlenecks and issues. All in all, it’s an all out co-operation of every engineering team involved with the tests and the systems being tested.