JMeter Learning (13) Distributed deployment

Jmeter is a Java application that consumes a large amount of CPU and memory, so when you need to emulate thousands of concurrent users, it is a bit of a problem to emulate all concurrent users with a single machine, or even cause a Java memory overflow error. In order for the JMeter tool to provide greater load capacity, JMeter has a mechanism for using multiple machines to generate loads simultaneously.

So, how to implement 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, everyone at the same time start JMeter. It's a stupid way to get real sync. In fact, we can control multiple remote JMeter servers through a single JMeter client, allowing them to synchronize the stress tests on the server.

By running JMeter remotely, testers can replicate tests across multiple low-end computers, simulating a larger server pressure, a JMeter client instance, theoretically controlling as many remote JMeter instances as possible, and collecting test data through them. In this way, you have the following features:

* Save test sample data to local machine

* Manage multiple JMeter execution engines with a single machine.

* It is not necessary to copy the test plan to each machine, and the JMeter GUI client will send it to each jmeter server.

* Each JMeter remote server performs the same test plan, JMeter does not load balance during execution, and each server runs the test plan in its entirety.

Thread 100~300 can be handled on a 1.4G Hz~3ghz CPU, 1GB memory JMeter client. But web Service exceptions. XML processing is CPU intensive and consumes all of the CPU quickly. Generally speaking, the application system with XML technology as the core, its performance will be the 10%~25% of ordinary Web application. In addition, if all the load is generated by one machine, both the NIC and switch ports can create bottlenecks, so the number of one JMeter client threads should not exceed 100.

Using JMeter remote mode is not more resource-intensive than running the same number of non-GUI tests independently. However, if a large number of JMeter remote servers are used, the client may be overloaded, or the network connection will be congested.

The following steps are used to generate the load using multiple machines:

(1) Install JMeter on all machines that expect to run JMeter as a load generator, and identify one of the machines as the controller and other machines as agents.

(2) Run the Jmeter-server file on all agent machines (assuming two machines 192.168.9.99 and 192.168.9.130 as agents)

(3) in the JMeter Bin directory of the controller machine, locate the Jmeter.properties file and edit the file:

Find:
remote_hosts=127.0.0.1
modified to:

Special attention is paid to the port, and some data indicate that port 1644 is the default RMI port number for communication between the Controller and the agent for JMeter, but when tested, it was found that the set to 1644 ran unsuccessfully and was changed to 1099 after it was run. Also pay attention to the agent's machine whether the firewall is turned on and so on.

(4) Start the JMeter application Jmeter.bat on the controller machine, select the menu "Run"---> "remote Start" to start the agent separately, or you can directly select "Remote Start All" to start all agents.

Common problems encountered:

1. Control a machine run on the controller side, prompting "bad call to remote host".   Workaround: Check whether the jmeter-server on the controlled machine is booting, or the configuration error remote_hosts in the jmeter.properties. 

2, Agent machine start Jmeter_server.bat, background prompt: "Could not find Apachejmeter_core.jar" solution: Determine the agent machine installed JDK, and set environment variable

3, remote startup, error:

error-jmeter.gui.action.remotestart:failed to initialise remote engine java.rmi.ConnectException:Connection refused T o 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.performAction (actionrouter.java:81)

This problem is finally solved by me, in fact the reason is very simple. As long as the server.bat of the machine can be executed.

Note: If you write the 127.0.0.1 in the configuration, the Sever.bat of the Folio machine is necessary. If you don't write, you don't have to open it.

4. Check if Port 1099 is occupied

Netstat-ano | Findstr "1099"
tasklist | Findstr "1099"