Jmeter (forty-seven) - From entry to advanced level - Load machine settings for distributed stress testing deployment (detailed tutorial)

1 Introduction

The long-awaited article has just begun to come out. It feels like it took me a long time to write this article. I always wanted to write it clearly and concisely, but I still wrote a lot of it eloquently. I hope you all like it! I originally planned to explain and share this article in the performance test, but some children's shoes or friends asked too many questions in private. I really couldn't bear it and got tired of answering it, so I just shared it here. It is only for reference, but I hope it will be helpful to everyone.

2. Why use distributed testing?

(1) Jmeter runs based on Java programs. When using Jmeter for performance testing on Windows, it consumes a lot of the client's CPU and memory. If the number of concurrencies is slightly larger (such as 100, 1000... concurrency), a single computer The configuration is often unsupported, and it is easy to get stuck. Even if it is not stuck, the computer will run very slowly, making it impossible for us to perform other operations.
(2) When performing performance testing through the cmd command line or using Jmeter on Linux, the required system resources can be greatly reduced; however, the jmeter script needs to be uploaded to Linux and run using the command line. If the script is frequently changed, Frequent uploading; after the test is completed, the result data must be downloaded to the local GUI environment for viewing. When the result file is large, downloading takes a lot of time, which is always inconvenient.
(3) According to the general press configuration, jmeter’s GUI mode (Windows) supports up to about 300 simulation request threads. If it is larger, it will easily cause lags, unresponsiveness, etc. This is limited to jmeter’s own mechanism. and hardware configuration.
(4) Sometimes in order to simulate business scenarios as much as possible, a large number of concurrent requests need to be simulated. At this time, a single press seems powerless. In response to this situation, JMeter's solution is to support distributed pressure testing, which is to allocate a large number of simulations to multiple pressure machines concurrently to meet this large-traffic concurrent request scenario.

Ordinary stress test: A single machine can exert relatively little pressure on the target machine. The limiting factors include CPU, network, IO, etc.
Distributed stress testing: Use multiple machines to generate pressure on the target machine and simulate concurrent access by tens of thousands of users.

If you want to learn automated testing, I recommend a set of videos to you. This video can be said to be the number one automated testing tutorial on the entire network played by Bilibili. The number of people online at the same time has reached 1,000, and there are also notes that can be collected and distributed by various channels. Master technical communication: 798478386

[Updated] A complete collection of the most detailed practical tutorials on Python interface automation testing taught by Bilibili (the latest practical version)_bilibili_bilibili [Updated] A complete collection of the most detailed practical tutorials on Python interface automated testing taught by Bilibili (practical version) The latest version) has a total of 200 videos, including: 1. Why interface automation is needed, 2. Overall view of request for interface automation, 3. Interface practice for interface automation, etc. For more exciting videos from UP master, please follow the UP account . https://www.bilibili.com/video/BV17p4y1B77x/?spm_id_from=333.337

3. Principle of distributed pressure measurement

1. In distributed testing, select one machine as the management machine (Contorller), and other machines as the agent machines (Agent) for test execution;

2. When executing the test, the Contorller sends the test script to the Agent through the command line, and then the Agent executes the test (without starting the GUI) and sends the test results to the Contorller;

3. After the test is completed, you can see the test results sent by the Agent in the listener on the Controller. The results are a summary of multiple Agent test results;

4. Preparations before starting

This short tutorial explains how to perform stress testing using multiple systems. Before we begin, there are a few things to check.

The firewall on the system is closed or the correct ports are opened.
All clients are on the same subnet.
If using the 192.xxx or 10.xxx IP address, the server is on the same subnet. If the server doesn't use 192.xx or 10.xx IP addresses, there shouldn't be any problems.
Make sure JMeter can access the server.
Make sure to use the same version of JMeter and Java on all systems. Mixed versions will not work properly.
You have set up SSL for RMI or disabled it.

Once you've determined that your system is ready, you can proceed to remote testing. This tutorial assumes that you have JMeter installed on all systems. The way JMeter works is that a controller node launches tests on multiple worker nodes.

In this tutorial, we only use GUI mode for demonstration. In real life you should use CLI mode (NON GUI) to start load testing

One Controller Node and Multiple Worker Nodes Before diving into the step-by-step instructions, it's a good idea to define the terms and make sure they are clear.

Controller Node: The system running the JMeter GUI (control test)
Worker node: A system running jmeter-server that receives commands from the GUI and sends requests to the target system
Target: The web server we plan to stress test

5. Ordinary pressure test

Ordinary stress test: A single machine can exert relatively little pressure on the target machine. The limiting factors include CPU, network, IO, etc. The following is a simple graphic description of a common pressure test. As shown below:

6. Introduction to Jmeter distributed pressure testing

In the scenario where jmeter is used for large-scale concurrent stress testing at work, and the memory, CPU, and network IO of a single machine are limited, the server pressure has not increased yet, but the stress test server has crashed due to too much simulated pressure. In order for the jmeter tool to provide more powerful load capabilities, jmeter provides a mechanism for multiple machines to generate loads at the same time. The following is the architecture diagram.

Principle: For example, if I configure the number of threads in jmeter server to be 10 and the number of cycles to be 100, that is, 1,000 requests will be made to the test server. I have 3 agent servers. If I choose to remotely start the stress test on the server side, then each The agent will initiate 10*100 requests to the test server, so the requests generated by this stress test are 10*100*3=3000 times.

If you don’t understand the principle very well, you will understand it after reading the following operations.

6.1JMeter distributed execution principle description

Prerequisite: Install JDK (we use version 1.8 here) + Jmeter (5.3) on the scheduling machine

1. The client machine (window system) serves as a controller to control the operations of multiple slave machines.
2. It is best to install the same versions of jdk and jmeter on the controller and slave machines, and configure the environment variables. The installation and configuration methods are similar to those in the windows environment.
3. The controller starts the slave machine through the GUI interface and sends the jmeter stress test script to each started slave. The slave starts execution after obtaining the script. The slave does not need to store the script in advance locally, but it does need to have dependent files in the script (such as csv files, etc.).
4. After the execution of each slave is completed, the results are sent back to the controller, which is collected and displayed by the controller.

7.Jmeter distributed stress testing environment construction

7.1 Instructions before building

Server environment description: For performance testing, you can directly purchase a press on the cloud platform on demand, and release the press once the test is completed. Of course, this depends on the company's resources and company situation. If it is really necessary to report to the leader in advance for funds or equipment, time, etc.

Distributed environment pressure server requirements:

A server (control machine) and an agent (press machine) are required. The agent is built in a Linux (centos 6.5) server environment, and the server is built in a Windows (server 2012) environment.
Most of the bottlenecks in stress testing are bandwidth. You need to ensure that the bandwidth of the press is higher than the bandwidth of the server, otherwise the pressure will not increase.
It is necessary to ensure that both the agent and the server are in the same network, and in a multi-network card environment, it is necessary to ensure that the started network cards are all in the same network segment.
It is necessary to ensure time synchronization between the server and the agent.
Turn off the firewall.

7.2 Configuration under windows

1. Install the same version of JDk and Jmeter on the Windows system (refer to the installation of the scheduler)

Note: Both JDK and Jmeter must configure environment variables

Configuration of Jmeter environment variables:

Add: JMETER_HOME=C:\jmeter\apache-jmeter-3.3\bin to the system environment variables

Add the following configuration to the path system variable: %JMETER_HOME%\bin;

7.2.1 Scheduler Controller

1. Configure jmeter according to the above steps on multiple machines, select one of them as the scheduling machine and the others as the execution machine. Brother Hong uses his local computer as a scheduling machine.

2. Modify JMETER_HOME/ on the scheduling machine bin/jmeter.propertiesand add the IP and port of the execution machine. 1099 is the default rmi communication port.

remote_hosts=192.168.174.130:1000,192.168.3.148:1888

In the code, 192.168.174.130:1000it is the execution machine IP and port number.

3. Uncomment server.rmi.ssl.disable=falsethe middle comment and change false to true, or copy this line of code and change false to true. Of course, don’t forget to remove the previous comment.

server.rmi.ssl.disable=true

4. Start the service on the machine that executes the script server, JMETER_HOME/bin/jmeter-server

5. Execute distributed commands on the control machine

#使用 -r 启动所有从机执行脚本
jmeter -n -t testplan/comic.jmx -r -l testResult/result1.jtl  

#指定从机IP
jmeter -n -t testplan/comic.jmx -R 10.15.243.53,10.15.230.78 -l testResult/result1.jtl

7.2.2 Executor Agent

1. The same principle as the dispatcher, find the corresponding code and modify jmeter.propertiesthe code in the file, as follows:

server_port=1000
server.rmi.localport=1000
server.rmi.ssl.disable=true

2. Customize the port number on the execution machine

(1) Enter the Jmeter bin directory, find the Jmeter.properties file, open the file and modify the following two configuration items, for example, modify the port number to: 1355 (the default port number is: 1099) (remember to uncomment)

server_port=1355
server.rmi.localport=1355
server.rmi.ssl.disable=true

(2) Start Jmeter-server.bat on the execution machine, as shown in the figure below, the port number has been modified to: 1000. Brother Hong has modified it to 1000 here.

3. Add a remote load machine to the dispatcher

Enter the Jmeter bin directory, find the Jmeter.properties file, and configure it as follows:

4. Open Jmeter on the dispatcher, as shown below to start the remote load machine

5. Verification: If it runs normally after startup, you can see the execution results of the remote load machine on the dispatcher, as shown below:

The following display appears on the execution machine:

7.3 Configuration under Linux

1. Install the same JDK and Jmeter versions as the scheduler under Linux

The configuration reference of JDK environment variables is as follows: https://www.cnblogs.com/du-hong/p/14428790.html

Jmeter’s environment variable configuration, export PATH=/opt/apache-jmeter-3.3/bin/:$PATH (configuration file location: /etc/profile) is as shown below:

Verification: Jmeter -v

2. Customize the port number on the execution machine

server_port=1355
server.rmi.localport=1099

3. Add a remote load machine to the dispatcher

Enter the Jmeter bin directory, find the Jmeter.properties file, and configure it as follows:

4. Open Jmeter on the dispatcher, as shown below to start the remote load machine

5. Verification: If it runs normally after startup, you can see the execution results of the remote load machine on the dispatcher, as shown below:

The following display appears on the execution machine:

8. Distributed pressure testing (all started)

1. Select Remote Start-->Remote All Start, as shown in the figure below:

2. Master results, all started, Hongge configured 2 slaves, so there are two execution results:

3. View the result tree and the execution machines (two machines with two results), as shown in the following figure:

Check the result tree as shown in the figure:

The execution machine is configured with a Linux system and a Windows system, as shown in the figure:

9. Summary

9.1 Problems encountered during actual combat

1. Jmeter-server fails to start under Linux, as shown in the following figure:

Solution: Add the following parameters when starting Jmeter-server, and complete the command as follows:

./jmeter-server -Djava.rmi.server.hostname=192.168.0.199

2、Neither the JAVA_HOME nor the JRE_HOME environment variable is defined

When using java to remotely start the jmeter service on the linux server, it reportsNeither the JAVA_HOME nor the JRE_HOME environment variable is defined，如下图所示：

Solution: Querying this error is basically a tomcat operation. Edit the file and add and jmeter/bin/jmeter-serverat the top .JAVA_HOMEJRE_HOME

3. The dispatcher reported the following error:

Solution: Set the port on the execution machine to a fixed port (how to customize the port has been explained in the previous deployment, refer to the above)

4. An error occurs when starting Jmeter: Java.net.ConnectionException: Connection refused:connect

Solve the problem: Restart the Jmeter-server service on the execution machine, or your service is not started at all (this can be solved in my test environment. If it cannot be solved in your environment, please carefully check the Jmeter-server on the execution machine. Error message in log)

5. Start Jmeter and report an error

Solution: 1. Find JMETER_HOME\bin\jmeter.properties
2. Modify server.rmi.ssl.disable=true (remember to remove the # before server.rmi.ssl.disable=true) and restart jmeter-server.bat

9.2 Other instructions

1. It is best to separate the scheduling machine (master) and the execution machine (slave). Since the master needs to send information to the slave and receive the test data returned by the slave, the master itself will consume, so it is recommended to use a separate machine as Mater.

2. Parameter file: If csv is used for parameterization, then the parameter file needs to be copied on each slave and the path needs to be set to the same.

3. It is best to have the same Jmeter version and plug-ins installed on each machine, otherwise some unexpected problems will occur.

4. If the number of concurrent threads set in the script is 100, and three slave machines are used to exert pressure, then for the server, the number of concurrent threads at this time is 300.

5. In order to reduce the possibility of errors, it is best to follow the following Jmeter distribution requirements:

Each machine installs the same version of jdk in the same directory;
Each machine installs the same version of jmeter in the same directory;
Configure the mapping between IP and hostname of /etc/hosts.
Modify the default memory parameters of jmeter on each machine from 512m to a suitable size.