Jmeter is a java application for CPU and memory consumption is relatively large, and therefore, when the need to simulate thousands of concurrent users, using a single machine to simulate all of concurrent users bloated, and even lead to memory overflow error JAVA. To make jmeter tool provides greater load capacity, jmeter a dapper With the use of multiple machines at the same time the mechanism of load.
So, how to achieve more than one machine while the load is running it? Of course, not more than one person sitting in front of multiple load machine, start a call, it started simultaneously jmeter. In this way stupid, it is difficult to achieve true synchronization. In fact, we jmeter by a single client can control multiple remote jmeter servers that are synchronized with the server stress test.
Jmeter by remote operation, the tester can span multiple low-end computers copy test, so you can simulate a relatively large pressure on the server, a client jmeter instance, in theory, can control any number of remote jmeter example, through them and collect test data. As such, there is the following features:
* Save test sample data to the local machine
* Execution engine through a single machine to manage multiple jmeter.
* There is no need to copy the program to test each machine, jmeter GUI client it will be sent to each jmeter server.
* Each jmeter remote server perform the same test plan, jmeter not do load balancing during execution, each server will run a complete test plan.
In a 1.4G Hz ~ 3GHz CPU, 1GB memory JMeter client, processing thread 100 to 300. But the Web Service exception. XML processing is CPU-intensive operations, it will quickly consume all of the CPU. In general, as the core technology in XML applications, its performance would be 10% to 25% of the ordinary Web applications. In addition, if all of the load generated by a machine, network cards and switch ports are likely to create a bottleneck, so a number of threads JMeter client should not exceed 100.
Using JMeter remote mode and does not consume more resources than running a non-independent GUI test the same number. However, if you use a lot of JMeter remote server, the client may cause overload, or a network connection is congested.
Generating a load using multiple machines following steps :
(1) mounted on the machine all desired operating jmeter jmeter generator as a load, and determining one of the machines as a controller, as other machines agent.
(2) All jmeter-server running on the agent machine file (assuming the two machines as 192.168.9.99 and 192.168.9.130 agent)
(3) in the bin directory jmeter the controller of the machine, find jmeter.properties file, edit the file:
Find: remote_hosts = 127.0.0.1 amended as: remote_hosts = 192.168.9.99: 1099,192.168.9.130: 1099
After paying particular attention to the port here, some information on RMI port 1644 to be the default port number for communication between the controller and jmeter agent, but when testing found that 1644 is set to run unsuccessful, changed after running through 1099. Also note that the machine is turned on the agent firewall.
(4) Start jmeter jmeter.bat applications on the machine controller, select the menu "Run" ---> "Remote Start" to start the agent, respectively, can also directly select "Remote Start All" to all of the agent started.
Common problems encountered :
1, on the Controller end of the Run a machine control, suggesting "Bad call to remote host".
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.performAction(ActionRouter.java:81)
I finally solved the problem, but in fact it is simple good reason. As long as the machine can perform the jmter-server.bat. If written in a configuration where jmeter.properties 127.0.0.1, then it should Folio machine jmeter-sever.bat. Do not write the words would not have opened
4, 1099 to see if the port is occupied
netstat -ano | findstr "1099"
tasklist | findstr "1099"
other instructions:
1, the scheduling unit (master) and actuators (slave) is preferably separated, since the need to send information to the master and slave return back to slave receive test data, the mater itself be consumed, it is proposed to use a single machine as mater.
2, the parameter file: If you use the csv parameterized, you need to copy a parameter file and the path needs to be set to the same on each slave.
3, Jmeter version and plug-ins installed on each machine are the best, or it will be some unexpected problems.