written in front
Usually, in the process of using Jmeter for stress testing, due to the limited concurrency capability of a single machine, it often cannot meet the requirements of stress testing. Therefore, Jmeter also provides a distributed solution. This article is a practical record of stress testing the business system login interface using Jmeter distribution. According to the usual practice, before the official start, let me briefly introduce the outline of this article:
- Jmeter rendezvous usage
- Detailed Explanation of Jmeter Command Line Parameters
- Jmeter distributed deployment scheme
- Jmeter distributed scheduling principle
- Jmeter distributed deployment process
- Jmeter distributed pressure measurement business system login interface practice
1. Jmeter rendezvous point usage
The rendezvous point is an unavoidable topic in stress testing using Jmeter.
The popular understanding of rendezvous is that, for example, to simulate 100 concurrent users, rendezvous will release all 100 threads after they are assembled, and put pressure on the system at the same time. In Jmeter, it can be done by synchronizing the timer Synchronizing Timer:
The relationship between the "number of simulated user groups" in the synchronous timer and the number of threads in the thread group:
1. When the number of simulated user groups = the number of threads in the thread group
For example, the number is 5, then run the test, Jmeter will wait until 5 users are ready at the same time, and initiate the request concurrently;
2. When the number of simulated user groups < the number of threads in the thread group
① No timeout is set
For example, if the number of simulated users is 5 and the number of threads is 8, then after running Jmeter, Jmeter will first initiate 5 requests at the same time, and the remaining 3 users are less than 5 of the rendezvous points. Since there is no timeout setting, the number of rendezvous points cannot be reached, and Jmeter will always be in a waiting state;
② The timeout period has been set
For example: the simulated user is 5, the number of threads is 8, and the timeout is set to 3000 (in milliseconds, which is 3 seconds)
Then after running Jmeter, Jmeter will first initiate 5 requests at the same time. Since the remaining 3 users are less than the number 5 required by the rendezvous point, it will wait for 3 seconds overtime, and then initiate the remaining 3 user requests at the same time after 3 seconds, a total of 8 users;
3. When the number of simulated user groups > the number of threads in the thread group
① No timeout is set
For example: the simulated user is 8, the number of threads is 5, and the timeout is 0
Since the number of simulated users set is 8, that is, the number of rendezvous points is 8, and the total number of users of the thread group is only 5, so the requirement for the number of rendezvous points is not met, and the timeout period is not set, so Jmeter will always be in a waiting state and will not initiate any requests, as shown in the following figure:
② The timeout period has been set
For example: the simulated user is 5, the number of threads is 8, and the timeout is set to 3000 (in milliseconds, which is 3 seconds)
Since the number of simulated users set is 8, that is, the number of rendezvous points is 8, and the total number of users of the thread group is only 5, so the number of rendezvous points cannot be met, but the timeout period is set to 3 seconds, so Jmeter will initiate 5 (user) requests at the same time after 3 seconds, as shown in the following figure:
2. Detailed explanation of Jmeter command line parameters
| parameter | effect |
|---|---|
| -n | Indicates running JMeter in command line mode |
| -t | specify script file |
| -R | Specify the slave node (agent) to execute the test, and multiple ips are separated by commas |
| -r | Indicates that all agents are started |
| -f | Indicates that the previous execution result will be cleared every time, and the new result will be written |
| -l | Generate a test result file, which ends with jtl by default |
| -e | Generate test report |
| -o | Specifies the location to generate test reports, must be empty |
| -g | Specify the existing test file ending in jtl to generate a report |
Common usage:
./jmeter.bat -n -t test.jmx # 以命令行方式运行test.jmx脚本
./jmeter.bar -n -t test.jmx -l test.jtl # 以命令行方式运行test.jmx脚本，并生成测试结果文件test.jtl
./jmeter.bar -n -t test.jmx -f -l test.jtl -e -o report # 以命令行方式运行test.jmx脚本，每次生成结果前先清空test.jtl，同时在report目录下生成测试报告
./jmeter.bar -n -t test.jmx -l test.jtl -R 192.168.1.122 # 指定远程主机192.168.1.122执行测试
复制代码3. Jmeter distributed deployment scheme
| the host | IP address |
|---|---|
| Master master node (Windows) | 192.168.1.131 |
| Slave from node-1 (Linux) | 192.168.1.121 |
| Slave from node-2 (Linux) | 192.168.1.122 |
| Slave from node-3 (Linux) | 192.168.1.123 |
Precautions:
- The master node and each slave node machine must have the Java environment installed in advance;
- The Jmeter version of the master node and each slave node remains unified;
- The master will send the jmx script file to each slave node when sending the test plan, so the script file does not need to be manually uploaded to each slave node;
- However, the master will not send external files together, so CSV and other parameterized files used in the test need to be manually uploaded to each slave node, preferably in the bin directory, and Jmeter will directly start searching from the bin directory;
4. Jmeter Distributed Scheduling Principle
1. The role of each node
- Master node: mainly responsible for managing slave nodes (load machines), assigning scheduling tasks (script distribution), and collecting test results
- Slave node: Execute test tasks and simulate concurrent requests
2. Workflow
① The master node is responsible for sending test tasks and test scripts to each slave node;
② After receiving the test tasks from the nodes, they start to drive Jmeter in their respective environments to execute the test tasks and simulate concurrent requests;
③ After the execution of the slave node is completed, the test result will be sent back to the master node;
④ Finally, the master node displays the test results collected from each slave node;
Five, Jmeter distributed deployment process
1. Master node deployment
① Edit the main node jmeter.properties configuration file
- Line 268, remote_hosts adds the host address of the slave node, and multiple slave nodes are separated by commas (note: there may be differences in different versions)
- Line 272, the port number of the master node, if there is a port occupied, it can be manually modified
- Line 345, server.rmi.ssl.disable changed from false to true (turn off ssl)
② The master node starts the jmeter-server service
In the Windows environment, just click the jmeter-server.bat in the bin directory of Jmeter to run it. If the startup is successful, the following prompt will appear:
2. Deploy from the node
① Upload the Jmeter compressed package to each slave node and decompress it
The slave nodes are all Linux environments, and the decompression command is:
unzip apache-jmeter.zip
复制代码② Modify the jmeter.properties configuration file
- Line 345, server.rmi.ssl.disable changed from false to true (turn off ssl)
③ Start the jmeter-server service
chmod -R +x bin # jmeter-server、jmeter文件都需要执行权限，可以简单粗暴使用chmod -R参数赋予整个bin目录执行权限
./jmeter-server # 启动jmeter-server服务
复制代码If the startup is successful, the following prompt will appear:
3. Test the connectivity between the master node and the slave node
You can select a slave node through the Jmeter tool - run - remote start; you can also use the command line -R parameter to specify a slave node to run:
As shown in the figure below, Starting... indicates that the master node has delivered the task to the specified slave node, and the slave node starts to execute the test task
4. Jmeter distributed deployment common problems and error resolution
1) Start the remote host and prompt "Engine is busy - please try later"
Reason: The local or remote load machine is not shut down normally
Solution: Kill the process and restart (you can observe the jmeter-server logs of the master node and the slave node. If there is only Starting and no Finished, then there is a high probability that there is a problem with this machine)
2) The master node did not receive the result data after initiating the test
For example: after the execution is successful, there is no data in the result tree, and there is no error reported by the master node and the slave node
Reason: There is parameterization in the test script, the parameterized csv file on the remote node is inconsistent with the directory set in the local test, or the csv file is missing from the slave node
Solution: Upload a copy of the csv file to each slave node. It is best to set a relative path for the csv file instead of an absolute path. Store the csv file in the bin directory
3) Jmeter starts the slave node to run the test and reports an error "connection refused"
Reason: The jmeter-server service has not been started from the node
Solution: Each slave node starts the jmeter-server service
6. Jmeter pressure measurement business system login interface practice
- Maximum concurrency: After communicating with the person in charge of our business system, I learned that the system theoretically supports about 6,000 to 7,000 users to log in concurrently at the same time, and there is no problem;
- The goal of the test: to test whether the business system supports concurrent logins of such a large number of users as the data provided by him;
- Measured data: 3 load machines, each of which started 500 threads, and a total of 1,500 concurrent users. The test results are as follows. The simulated users of each load machine log in normally without error reporting, and there are no major fluctuations in the memory and CPU of the server where the business system under test is located;
- Boost: The number of concurrent users is around 1500 and 2100, and the system response is relatively stable. When the number of concurrent users reaches 1000 per machine, a total of 3000 users request at the same time, some users will return 500 for login, and the overall failure rate is about 3%.
summary
- The above is a practice of using Jmeter to realize distributed pressure measurement, to be precise, it should be a preliminary study;
- During the stress test, I did not monitor the dynamic changes of CPU and memory in detail, and I will use the monitoring combination of JMeter+InfluxDB+Grafana to visualize the monitoring test process;
- Performance testing is a huge project and proposition. Performance testing tools are only a technical means to implement performance testing. Knowing how to use performance testing tools does not mean that you have mastered performance testing;
- The purpose of all performance testing tools is to simulate the initiation of pressure. In the process of performance testing, the tools only play the role of script development, scenario realization, and test execution, while performance testing also includes requirements acquisition, scenario design, result analysis, and tuning. Ultimately, it depends on people to achieve;
- Especially performance bottleneck analysis and tuning, in addition to relying on performance test results, it also needs to rely on people's strong performance testing skills, as well as understanding of business and system architecture;
Software testing learning resource sharing
Finally, I would like to thank everyone who has read my article carefully. Seeing the fans’ growth and attention all the way, there is always a need for reciprocity. Although it is not a very valuable thing, you can take it away if you need it:
The complete software testing video learning tutorial below has uploaded the QR code officially certified by CSDN. If you need it, you can get it for free [guaranteed 100% free]
These materials should be the most comprehensive and complete preparation warehouse for friends who want to advance [automated testing]. This warehouse has also accompanied me through the most difficult journey, and I hope it can help you too! Everything should be done as early as possible, especially in the technical industry, we must improve our technical skills. I hope it will be helpful to everyone... Basic knowledge, Linux essentials, Shell, Internet program principles, Mysql database, packet capture tool topics, interface testing tools, advanced testing-Python programming, Web automated testing, APP automated testing, interface automated testing, testing Advanced continuous integration, testing framework development testing framework, performance testing, security testing and other supporting learning resources are free to share
