Jmeter Learning (13) distributed deployment

Jmeter is a Java application that consumes a large amount of CPU and memory. Therefore, when thousands of concurrent users need to be simulated, it cannot be used to simulate all concurrent users on a single machine, it may even cause Java memory overflow errors. To enable the jmeter tool to provide greater load capabilities, jmeter has a mechanism that uses multiple machines to generate load at the same time.

So, how does one achieve simultaneous operation of multiple load servers? Of course, there won't be many people sitting in front of multiple load-bearing machines. When everyone starts jmeter at the same time. This method is stupid and hard to achieve real synchronization. In fact, we can use a single jmeter client to Control Multiple Remote jmeter servers so that they can simultaneously perform stress tests on the servers.

By remotely running jmeter, testers can copy and test data across multiple low-end computers to simulate a large server pressure and a jmeter client instance, theoretically, you can control any number of remote jmeter instances and collect test data through them. In this way, the following features are available:

* Save the test sample data to the local machine.

* Manage multiple jmeter execution engines on a single machine.

* There is no need to copy the test plan to each machine. The jmeter GUI client sends it to each jmeter server.

* Each jmeter remote server executes the same test plan. jmeter does not perform Load Balancing during execution, and each server runs the test plan completely.

 

In the range of 1.4G Hz ~ 3 GHz CPU, 1 GB memory jmeter client, can process thread 100 ~ 300. However, the Web service is not supported. XML processing is intensive in CPU operations and will quickly consume all the CPUs. Generally, the performance of an application system with XML technology as the core is 10%-of that of a common web application ~ 25%. In addition, if all the loads are generated by one machine, the NIC and switch ports may cause bottlenecks. Therefore, the number of threads on a jmeter client should not exceed 10.

Using the jmeter remote mode does not consume more resources than running a non-Gui test with the same number of independent tasks. However, if a large number of jmeter remote servers are used, the client may be overloaded or the network connection may be congested.

 

The procedure for using multiple machines to generate loads is as follows:

(1) install jmeter on all machines that want to run jmeter as the load generator, and determine one of them as the controller and the other as the agent.

(2) run the jmeter-Server File on all the agent machines (assuming two machines 192.168.0.100 and 192.168.0.101 are used as the agent)

(3) Find the jmeter. properties file in the bin directory of jmeter on the Controller machine and edit the file:

查找：remote_hosts=127.0.0.1修改为：remote_hosts=192.168.0.100:1099,192.168.0.101:1099 

Pay special attention to the port. Some information indicates that port 1644 is the default RMI port number for communication between the Controller and agent of jmeter. However, during the test, it is found that the port is set to 1644 and failed to run, change to 1099 and then run it. In addition, pay attention to whether the firewall is enabled for the agent host.

 

(4) Start the jmeter application jmeter on the controller. bat, select "run"> "remote start" from the menu to start the agent separately. You can also directly select "remotely start all" to start all agents.

 

Common problems:

1. Control the run of a machine on the controller. The message "bad call to remote host" is displayed ".

Solution: Check whether the jmeter-server on the controlled machine is started or the remote_hosts configuration in jmeter. properties is incorrect. 2. When the agent machine starts jmeter_server.bat, the background prompts: "cocould not find apachejmeter_core.jar" solution: confirm to install JDK on the Agent machine and set the environment variable. 3. When the agent machine is remotely started, an error is reported:

Error-jmeter. Gui. Action. remotestart: failed to initialise remote engine java. RMI. connectexception: Connection refused to host: 127.0.0.1; Nested exception is:
Java.net. connectexception: Connection refused: connect
At sun. RMI. Transport. tcp. tcpendpoint. newsocket (unknown source)
At sun. RMI. Transport. tcp. tcpchannel. createconnection (unknown source)
At sun. RMI. Transport. tcp. tcpchannel. newconnection (unknown source)
At sun. RMI. server. unicastref. newcall (unknown source)
At sun. RMI. Registry. registryimpl_stub.lookup (unknown source)
At java. RMI. Naming. Lookup (unknown source)
At org. Apache. jmeter. Engine. clientjmeterengine. getengine (clientjmeterengine. Java: 54)
At org. Apache. jmeter. Engine. clientjmeterengine. <init> (clientjmeterengine. Java: 67)
At org. Apache. jmeter. Gui. Action. remotestart. doremoteinit (remotestart. Java: 180)
At org. Apache. jmeter. Gui. Action. remotestart. doaction (remotestart. Java: 80)
At org. Apache. jmeter. Gui. Action. actionrouter. Action maction (actionrouter. Java: 81)

I cannot solve this problem for the time being. I hope someone can give me some advice. I have referred to some materials and wrote above that I want to change 127.0.0.1 in ETC/hosts to the actual IP address. I also modified it and reported this error, I don't know if this problem is caused by the inconsistent JDK version of my control and agent.

 

Jmeter Learning (13) distributed deployment