JMeter (iv)-distributed performance testing

One: Introduction

Jmeter concurrent testing for the local load machine CPU and memory consumption is large, when the need to simulate thousands of concurrent users (equivalent to open thousands of of threads), the use of a single machine to simulate all concurrent users is somewhat inadequate, and even caused a Java memory overflow error. In order for JMeter to provide greater load capacity, it is possible to use multiple machines to generate load at the same time by JMeter.
So, how to achieve multiple load machine running at the same time. Of course not many people sit in front of more than one load machine, a shout start, we also start jmeter. This is a stupid way and it's hard to achieve real synchronization. In fact, we can control multiple remote JMeter servers with a single JMeter client to synchronize the pressure test on the service end.
　　
Schematic diagram:

By running JMeter remotely, you can simulate a larger server pressure, a jmeter client that can theoretically control any number of remote JMeter servers and collect test data from them. As a result, they have the following characteristics:
(1) Save test data to local machine
(2) Manage multiple JMeter execution engines through a single machine.
(3) There is no need to copy the test plan to every machine, JMeter, the client will send it to each jmeter server.
(4) Each JMeter remote server performs the same test plan, and each server runs the test plan in its entirety. Two: Operation Steps

Install JMeter on all machines that expect to run Jmete (version must be consistent) and identify one of the machines as the controller and the other machines as agents

(2) running all the%jmeter_home%/bin/directory Jmeter-server.bat files on all agent machines (assuming the use of three machine IP for 192.168.1.101 and 192.168.1.102,192.168.1.103 As agent)
Make sure that both the controller and the agent are in a subnet.

(3) Jmeter.properties files on the%jmeter_home%/bin/directory on the controller machine,
Find: remote_hosts=127.0.0.1
Modified to: remote_hosts=192.168.1.101:1099,192.168.1.102:1099,192.168.1.103:1099
Here to pay special attention to the port, some data show that port 1644 is JMeter controller and agent communication between the default RMI port number, but found in the test, set to 1644 run unsuccessful, changed to 1099 after the run. Also pay attention to whether the agent's machine opened the firewall, etc. (must be turned off).

(4) Start the controller machine on the%jmeter_home%/bin/directory Jmeter.bat, select the menu "Run"-> "remote Boot" to start the agent separately, you can also directly select "Remote all start" to all the agent to start.

At this point, for example, our test plan requires performance to be 1200 concurrent, and then we have 3 agents (at which time the controller device does not execute the concurrency data), and when we write the performance test script, the concurrency number is written as 1200, Controller automatically assigns performance pressure, and each agent runs the same concurrency number.

If you need to use the controller device as an agent to participate in generating concurrent data, it means that there is a device that needs to be concurrently controller and agent. In this case, you need to modify the Jmeter.properties file to write the controller IP address. Then, you need to open the Jmeter-server.bat in the Controller%jmeter_home%/bin directory and then open Jmeter.bat, and then go to the Run->remote Start menu, You can see that controller is also running as a remote machine.