Distributed Load Testing Using JMeter on the Cloud

Distributed Load Testing Using JMeter on the Cloud

Load testing is a crucial step before releasing any software that requires serving hundreds of users in real time. This involves simulating similar actions of real users by making requests from computer created virtual users. In most of the cases, load cannot be generated by a single server to simulate a large number of real users due to limited hardware resources of a single computer. Additionally, physically distributed servers are needed if separated user behavior is desired from different regions of the world. For large scale load generation, you can create geographically distributed load tests which use many servers to simulate the load on the target system. Distributed tests also mimic real user behavior more closely to real user requests by efficient use of balanced resources.

The test infrastructure reserved to load tests can be very expensive and difficult to maintain because it is not required on a continuous basis. Furthermore, dedicated test resource provisioning with a static capacity is difficult to scale beyond the initial configuration. This is also costly due to the infrequent usage of the reserved hardware resources.

Internal Network Implementation of Distributed JMeter Test

For example, the necessary infrastructure components required for a load test can be created within minutes and can be destroyed when tests are finished. There are different approaches and tools when it comes to distributed load testing. Apache JMeter is one of the free, complete and mature alternatives of performance engineers. JMeter can be started in a distributed mode as similar to other competing software. JMeter works as one master (manager) controller initiates and controls the test on multiple slave (remote) servers. The communication between master and slave servers are handled via RMI –remote method invocation where signed (stub) remote methods can be called by the main method managed by a master node. The master node is able to “speak” with the slave nodes and let them generate requests simultaneously on the target system. (Usually called System Under Test — SUT)

The configuration of Jmeter in distributed mode is pretty easy. But there are a couple of prerequisites to check:

• All slaves should be on the same network. Proxy servers are needed if different subnets exist.
• Use the same version of JMeter in all servers; both slaves and master.
• Make sure that JMeter can access SUT.
• Check the firewall rules and add exceptions for specific ports.

On the slave systems, go to JMeter/bin directory and execute JMeter-server.bat. You need to add every slave systems’ IP address into jmeter.properties file stored under JMeter/bin directory at the master node. Find line remote_hosts=127.0.0.1 and add IP addresses separated by commas:

remote_hosts=192.168.0.10, 192.168.0.11, 192.168.0.12

Start JMeter, on the master node. That’s all!

Since this post uses standalone virtual machines for the distributed load generation, another alternative is the usage of containerized architectures such as Kubernetes, rkt, Mesos, OCI and more. Containers offer a lightweight alternative to running full virtual machine instances for applications and are well-suited for rapid scaling of simulated clients. JMeter is simple, light jar file and can be containerized and managed by a let say Kubernetes. Thus you can create more requests but use fewer resources.

Why You Should Go Cloud

The solution is simple. For all those reason stated above, cloud-based resource provisioning that provides a high degree of flexibility in terms of cost, time bandwidth is necessary. Running your test on the cloud with tools like Loadium would be beneficial for your business to increase hardware investment and maintenance efforts.