Is it possible for a single machine to generate thousands of user requests and send them to the server? Would you consider this to be a genuine test scenario?
Although we set up distributed load to simulate a real-time scenario, it’s known that a single machine cannot generate a high number of requests on its own, because the device will hang or crash. So, an approach known as distributed load testing is the way to go whenever we need to test for a high number of user requests.When we perform a real-time test, it’s preferable to generate the load from different machines, as well as from different geolocations. Distributed Load Testing is where a heavy load is generated using multiple load generators. In standard load testing, the load is generated from a single machine, but to test huge user demand in real-time, we may need to distribute the load across different devices in different geolocations.
When Distributed Load Testing Important
- When there is a huge user demand to be simulated which may be difficult to achieve from a single load-generating machine
- When real-time (real browser) test conditions need to be tested
- When testing from different geolocations is needed
- The scalability of the servers to be tested
- Whenever the load generator doesn’t have enough resources to generate the load
Distributed Load Testing Process Using Jmeter
Let’s take a look at the distributed load testing process through JMeter, a popular open source load testing tool. In JMeter, we have a master, a few slaves and the target.
- Master: This is the test controller, or in other words, it’s where you will have the tests running from the JMeter GUI.
- Slaves: Slaves takes command from the master and generate requests to hit the server.
- Target: This is where the application under test is hosted.
There can be multiple slaves to distribute the load by taking the commands that they receive from the master. The JMeter UI will only be running on the master machine since has the sole responsibility for monitoring the tests and generating the report. The master machine doesn’t generate load, but will command the slave machines to do so. Slave machines should only be set up with the JMeter server since only they are responsible for sending the requests, but there can be problems when using JMeter because the master and all the slaves will have to be on the same subnet. Also, because a single JMeter can only handle about 500 simultaneous requests, you will have to use multiple machines with JMeter servers, if you want to load test for hundreds of thousands of users, which is not practical to do all the time. Hence, whenever there is the need to load testing for a large volume of users, you will have to rely on commercial cloud-based load testing tools such as Neoload, and Blazemeter etc.
Benefits to using cloud-based tools for distributed load testing
- Cloud-based solutions provide dedicated load generators from different geolocations which allow us to emulate real user transactions
- Integration of load test on mobile platforms: We will be able to emulate the user transactions from mobile devices separately
- Integrating load tests with CI/CD process
Conclusion
While distributing the load, it’s always preferable to use cloud-based solutions since they can provide better resources at lower cost. Using local machines is not only costly, but can also yield false positive results because of network or system latency issues. Even if you’re not planning to use commercial tools, it is preferable to host open source load testing tools on cloud vendors such as Amazon or Azure, to be safe in the knowledge that you can scale up your tests based on your changing needs.
