Jmeter Distributed Performance Test Pit Avoidance Guide

When doing backend server performance testing, we will often hear 'distributed'. So, do you understand distributed? Today, we will tell you how to use distributed performance testing in enterprise actual combat, and what places should we pay special attention to during actual combat?

 

Why use distributed?

When doing performance testing, if the performance of the system under test is relatively good, or the system project is relatively large, it is generally required to support a relatively high number of concurrent users. When we do performance testing, the hardware resources of the machine that initiates the request are fixed, and it is impossible to configure an infinite number. Therefore, the number of concurrent users it can initiate is limited, and when we initiate a computer, the number of concurrent users that can be initiated When the number of concurrent users is less than the number of concurrent users expected by our performance test, we will naturally think of increasing the initiator's computer. Increase the number of initiator computers, then the cumulative number of concurrent users initiated will increase.

A computer on the initiator side, whether it is a windows system or a linux system, generally speaking, can support about 1.5k concurrent users, and more concurrent users must adopt distributed.

So, the next question is how to configure distributed?

How to configure distributed?

• Assist machine configuration, modify the jmeter.properties file First, we prepare multiple machines as assist machines; then, check whether jdk is installed on each machine, and whether the jdk version is consistent; then, place the same version on the assist machine jmeter; Next, configure the jmeter.properties file, modify the server_port port, customize a port, modify server.rmi.ssl.disable=true, modify the server.rmi.port port ---- optional start service: jmeter-server -Djava .rmi.server.hostname=ip_address Check the firewall, close or open the custom server_port port
• Main control machine configuration, modify jmeter.properties file, modify remote_hosts, value is assisted machine ip modification, server.rmi.ssl.disable=true modification, mode=Standard

What are the considerations for distributed machine configuration?

Isn't distributed configuration very simple?

Yes, this configuration is actually not difficult at all. If you want to practice by yourself, follow the above operation, and you can easily configure it successfully. However, when you actually fight in enterprise projects, is it still so simple? If your enterprise project needs to support tens of thousands of concurrency and use dozens of assist machines, can you simply repeat the above operations?

the answer is negative.

Now there are dozens of linux machines, placed in front of you, for you to configure as assist machines. The quantity is relatively large, and there is no guarantee that each one is exactly the same, so we must first check the machine configuration.

• 1. Hardware resources cpu and memory are the core of a computer. There are dozens of machines, and we cannot guarantee that each one is the same. In the requirements of the assist machine, although there is no requirement for cpu and memory, if each If the resources provided by each machine are different, the number of concurrent users that can be generated will definitely not be equal. Therefore, we need to find out the machine with the lowest configuration among the machines, and then configure the stack information of jmeter with the lowest configuration machine as a reference . . Use the top command to view the cpu and memory information of each system and modify the jmeter file HEAP:="-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m" in the bin folder of jmeter to modify the size in the stack information. Without configuration, jmeter may have OOM problems when executing a high number of concurrent users
• 2. There are too many jdk machines in the system environment. Whether the jdk version of each machine is consistent may be a problem. If it is not installed on the machine, how can you just install the specified version directly? However, if other versions of jdk have been installed on the assist machine and other java projects are running, what should I do at this time? Specify the running jdk version of jmeter 1. Download and decompress the specified jdk version to the /usr/local folder of linux, do not configure and change the system environment variables 2. In the jmeter file of jmeter, add JAVA_HOME=/usr/local/jdk version / Specify the jdk version that jmeter runs, so that there is no need to change the jdk of the operating system, and it will not affect other java projects in the system jmeter jmeter version All jmeter versions on the assisting machine must be consistent . To modify ssl.disable=true in jmeter.properties , the ports can be different. If third-party plug-ins are used in the code , these plug-in packages must also be installed on the assist machine . jmeter runs, and the JMETER_HOME environment variable itself does not need to be configured. However, When there are too many machines, it is recommended to configure the JMETER_HOME environment variable HEAP on all machines. There are too many machines, and the memory of each machine may be different. We expect the assist machine to generate a larger number of concurrent users. Therefore, it is recommended to modify each The HEAP configuration information of each machine is set to the same csv file. If the csv data file setting is used in the jmeter script written, please use the relative path writing method for the path of the file. Under which path the jmeter-server assist service starts, it is necessary to upload the csv file to the relative location under the path on all machines.os operating system os version: no requirement, it can be different versions port range: the number of ports of the operating system is limited, different systems, by default, the number of open ports may not be equal, which requires us to configure each machine The range of ports opened on . sysctl -a | grep net.ipv4.ip_local_port_range This command can view the port range enabled on the current machine sysctl -w net.ipv4.ip_local_port_range="1024 65534" and then execute sysctl -p to take effect. In this way, set the port range opened on each machine. The number of open files The operating system has a limit on the number of files that each program can open. This is a system limit . We can see it through ulimit -n, or we can use cat /proc/process id/limit to check whether a process can open today. The number of open files is limited. Because the performance test assist machine also needs to initiate a large number of requests, which may open a large number of files. If the limit on the number of files is too small, it will also cause problems. Therefore, we can modify the number of files that the process can open through ulimit -n number quantity. Then, restart the jmeter-server assist service, so that it will be limited by the number you modified. There are too many time assist machines, and the time of each machine may be different. We can check the time of each machine through date. For performance testing, the expectation is that a large number of requests can be initiated at the same time. If the times of multiple machines are inconsistent, the number of requests initiated at the same time may not meet the expected requirements. Therefore, we need to set the time of each machine synchronously . date -s time to set the system time.
• 3. There are dozens of machines in the network environment, and the network configuration may be different. If there is a problem in the network between these assisting machines and the server under test, then it may cause the request pressure to fail, or even a network error. We can use the tracepath server under test on each assist machine to view the network situation between the assist machine and the server under test . If you find that the network delay time is very long, it means that there may be a problem with the network configuration of the current machine. When using it, it may be necessary to eliminate this assist machine.
• 4. Start the service on each assist machine: jmeter-server -Djava.rmi.server.hostname=ipaddr Since the ip address of each machine is different, this command must be typed one by one. At the same time, we can add an '&' symbol to convert the command to run in the background. Execute on the master machine: java -Xms48g -Xmx48g -XX:MaxMetaspaceSize=2g -jar $JMETER_HOME/bin/ApacheJMeter.jar -n -R xxx:port,xxx:port -t xxx.jmx -l xxxx.jtl - e -o xxdirect -Xms48g -Xmx48g -XX:MaxMetaspaceSize=2g This is to set the stack information of the main control machine jmeter. This size can be flexibly modified according to the memory size of your own machine, but this must be set relatively large . If it is small, the time to generate the report will be very long. $JMETER_HOME/bin/ApacheJMeter.jar specifies the assist machine for your own jmeter path -R xxx:port,xxx:port. Can be specified according to your needs. If you don’t need to use distributed, you don’t need this section. If you want to use distributed, you need to use this section. When there are more than one, use commas to separate them . -t xxx.jmx The jmeter script file you put on the master machine

Okay, have you learned all these precautions?