Distributed Performance Testing with JMeter
Last updated: January 8, 2024
Mocking is an essential part of unit testing, and the Mockito library makes it easy to write clean and intuitive unit tests for your Java code.
Get started with mocking and improve your application tests using our Mockito guide:
Handling concurrency in an application can be a tricky process with many potential pitfalls. A solid grasp of the fundamentals will go a long way to help minimize these issues.
Get started with understanding multi-threaded applications with our Java Concurrency guide:
Spring 5 added support for reactive programming with the Spring WebFlux module, which has been improved upon ever since. Get started with the Reactor project basics and reactive programming in Spring Boot:
Since its introduction in Java 8, the Stream API has become a staple of Java development. The basic operations like iterating, filtering, mapping sequences of elements are deceptively simple to use.
But these can also be overused and fall into some common pitfalls.
To get a better understanding on how Streams work and how to combine them with other language features, check out our guide to Java Streams:
Explore Spring Boot 3 and Spring 6 in-depth through building a full REST API with the framework:
Yes, Spring Security can be complex, from the more advanced functionality within the Core to the deep OAuth support in the framework.
I built the security material as two full courses - Core and OAuth, to get practical with these more complex scenarios. We explore when and how to use each feature and code through it on the backing project.
You can explore the course here:
Spring Data JPA is a great way to handle the complexity of JPA with the powerful simplicity of Spring Boot.
Get started with Spring Data JPA through the guided reference course:
Refactor Java code safely — and automatically — with OpenRewrite.
Refactoring big codebases by hand is slow, risky, and easy to put off. That’s where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.
Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions — one for newcomers and one for experienced users. You’ll see how recipes work, how to apply them across projects, and how to modernize code with confidence.
Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.
Distributed systems often come with complex challenges such as service-to-service communication, state management, asynchronous messaging, security, and more.
Dapr (Distributed Application Runtime) provides a set of APIs and building blocks to address these challenges, abstracting away infrastructure so we can focus on business logic.
In this tutorial, we'll focus on Dapr's pub/sub API for message brokering. Using its Spring Boot integration, we'll simplify the creation of a loosely coupled, portable, and easily testable pub/sub messaging system:
Distributed systems often come with complex challenges such as service-to-service communication, state management, asynchronous messaging, security, and more.
Dapr (Distributed Application Runtime) provides a set of APIs and building blocks to address these challenges, abstracting away infrastructure so we can focus on business logic.
In this tutorial, we'll focus on Dapr's pub/sub API for message brokering. Using its Spring Boot integration, we'll simplify the creation of a loosely coupled, portable, and easily testable pub/sub messaging system:
1. Overview
In this article, we’ll explore distributed performance testing using JMeter.
2. What Is Distributed Performance Testing?
Distributed performance testing means using multiple systems with the master-slave configuration to test a web application or a server’s performance.
In this process, we’ll use a local client as a master that handles the test execution using multiple remote clients, and each remote client acting as a slave will execute the test on our target server.
Each slave system executes the load tests following the exact condition set by the master. Therefore, the distributed performance testing helps us achieve a higher number of concurrent users requesting the target server.
In simple terms, the outline of the distributed performance testing using JMeter will look like:
3. Setup
3.1. Prerequisites
We should follow a few prerequisites for a smooth setup and test run:
- Multiple computers with JMeter installed on each
- Firewalls on the systems are turned off, or required ports are opened for connection
- All systems (master/slave) are on the same subnet
- JMeter on each system can access the target server
- Use the same version of Java and JMeter on all systems (master and slave)
- For simplicity, disable the SSL for RMI
Now that we have our systems ready, let’s configure the slave and master systems.
3.2. Configure the Slave System
On the slave system, we’ll go to the jmeter/bin directory and execute the jmeter-server.bat file on Windows. Or, we can run the jmeter-server file on Unix.
3.3. Configure the Master System
On the master system, we’ll go to the jmeter/bin directory and edit the remote_hosts property in the jmeter.properties file to add IP addresses (comma-separated) of the slave systems:
remote_hosts=192.165.0.10,192.165.0.20,192.165.0.30Here, we’ve added three slave systems.
So, by starting the JMeter (master) in the GUI mode, we can confirm all the slaves listed in the Run > Remote Start option:
That’s it! We’re ready to start the JMeter master system to execute tests on the target server using multiple clients.
4. Remote Testing
For remote testing, we can run JMeter in GUI mode for simplicity. However, we should run it using CLI mode when performing actual tests.
First, we’ll create a simple test plan in the master system that contains the HTTP Request sampler to request our baeldung.com server, and a View Results Tree listener.
4.1. Starting a Single Slave
Then, we can choose which slave system to run using GUI mode by using the Run > Remote Start option:
4.2. Starting All Slaves
Similarly, we can choose to run all slave systems by using the Run > Remote Start All option:
Additionally, a few options are available to handle test execution on the slave systems like Remote Stop, Remote Stop All, and Remote Shutdown All.
4.3. Test Results
Finally, we can see the test results in the local JMeter (master) once test execution finishes:
Also, on the remote JMeter systems (slaves), we can find logs about the start/stop of the test execution:
Starting the test on host 192.165.0.10 @ Sun Oct 25 17:50:21 EET 2020
Finished the test on host 192.165.0.10 @ Sun Oct 25 17:50:25 EET 20205. Conclusion
In this quick tutorial, we’ve seen how to get started with distributed performance testing using JMeter.
First, we looked at a few prerequisites for a smooth setup and test run. Then, we configured our slaves and master systems for a distributed performance testing environment.
Last, we started the slave systems, ran tests from a master system, and observed the results.
