In this post we are going to get major insights on “What is Performance Testing and how to perform distributed testing in Jmeter?” we will also be installing apache Jmeter5.1.1 , so let’s get started.
What is Performance Testing?
Before you start talking about distributed tests it is worth spending a few words on performance tests themselves. Let’s also limit the scope of this blog to web applications.
Performance Testing is a type of non-functional software test that aims to ensure that an application will perform according to the business requirements under its expected workload. By allowing you to check whether the application meets requirements such as response time, stability, and scalability. Its focus is not to find bugs but to identify bottlenecks, which may be in the application architecture or its infrastructure.
What is the importance of performance testing?
Performance issues, when not identified and fixed, can harm the user experience or even take a web application off the air.
According to data from Adobe Analytics, Amazon’s U.S. website sold $6.2 billion in one day on Black Friday 2018. We can do several simplifications to get at least an order of magnitude from the cost of having Amazon’s website off the air.
Performance testing and distributed testing in JMeter
To reproduce realistic application scenarios, we need to create several users (maybe a few thousand of them) and manage how they interact with the application, as well as harvest metrics from each request for further consolidation. It’s unthinkable to do this manually. The viable form is through automation and the use of tools such as JMeter, Gatling, and Locust.
We usually run these tests from a test machine and point to the address of the web application we want to test. As the number of virtual users used grows, so do the computational and memory costs of the machine that runs the tests beyond runtime.
Types of Performance Testing
Below are the types of performance testing:
Tests the software under normal usage conditions to identify system behavior under an expected specific load. What can be, number of simultaneous users, response times, number of requests answered per second or minute, etc? It is usually performed in a non-productive environment, as the test is performed with a controlled load. Therefore, it is possible to evaluate the performance of the application without impacting Production.
Tests the software under extreme conditions of use, to check the robustness of the system to find the limit of the application. This type of test is the most common to ensure that your application supports excessive load spikes in short periods, such as:
- Launch of Website and/or Products
- Buying Tickets at Events
- Release of emergency aid
- Soak test
Tests the software with a continuous load for long periods to determine whether the system will behave appropriately in memory usage during testing. Also important, to identify whether the behavior of the application will not be degraded during the test.
The number of maximum requests or users that request supports, the difference for load testing is that in a short period you force the application with as many users/requests. That is, you identify the point at which the application can no longer fulfill the requests.
Distribution testing in JMeter
JMeter, like other similar tools, supports distributed tests with a Master-Slave architecture where the Master is responsible for coordinating and consolidating the test results performed by each Slave against a Target.
Communication between Master and Slaves takes place via Java RMI (Remote Method Invocation).
- Distribution testing in Jmeter
- Master-Slave Architecture
Master — system running JMeter GUI, which controls the test
Slave — JMeter-server running system, which receives master commands, sends requests to the target system and returns results to the Master
Target – web system to be tested
If you are excited and want to try this let's start:
Install JMeter 5.1.1 on both machines (different versions may not work well)
Machines must be on the same network (same subnet to be more accurate)
In this configuration we will have the Master also run tests, then your IP address will be included in the list of remote_hosts.
In apache-jmeter-5.1.1/bin/jmeter.properties (also see apache Jmeter 5.2) ensure the following lines:
- remote_hosts=<IP of the machine 1>,<IP of the machine 2>
- server.rmi.ssl.disable=true #Essa line disables SSL.
- In a nutshell: users, passwords, and session cookies will travel unencrypted, in full text. Not suitable for corporate networks.
- Restart the JMeter after changing the file above.
- Run the JMeter server found on apache-jmeter-5.1.1/bin/jmeter.properties on both machines via console:
jmeter-server (Linux/Mac OS)
Let’s sum it up
To run the tests on only one of the machines, navigate to Run > Remote Start and select the machine from your IP address. To run the tests on all available machines, click Run > Remote Start All. At this point you can observe, in the terminal of the two machines, messages indicating the beginning and end of the tests. In the graphical interface of JMeter, we can see the results reported by the test machines. Visually there are no differences concerning a single machine run.