Shulou(Shulou.com)06/03 Report--

Video address: http://edu.51cto.com/lecturer/4626073.html

Background of using Jmeter distributed testing

1. Background of using Jmeter distributed testing:

1. The difference between GUI and non-GUI

First of all, we know that Jmeter has two modes of operation, GUI and non-GUI.

GUI: running on the Windows system, graphical interface, easy to view test results, but high consumption of press resources, easy to get stuck, and concurrency restrictions.

Non-GUI: run through the command line, no graphical interface, it is not convenient to view test results, but it consumes less press resources and can support greater concurrency.

2. Problems encountered by GUI and non-GUI

Jmeter is based on the java program. When using Jmeter on windows for performance testing, it consumes a lot of CPU and memory of the client, if the number of concurrency is slightly larger (such as 100,1000. Concurrency), the configuration of a single computer is often unable to support, it is easy to get stuck, even if it is not stuck, it will make the computer run very slowly, making it impossible for us to do other operations.

Through the cmd command line, or on the Linux using Jmeter for performance testing, can greatly reduce the required system resources; but you need to upload the jmeter script to Linux to run using the command line mode, if the script changes frequently, you will upload frequently; after the test is completed, you have to download the result data to the local GUI environment to view, when the result file is large, it takes a lot of time to download, and there is always a lot of inconvenience.

3. How to solve the problem?

All of the above problems can be solved by using Jmeter's distributed testing feature:

Through the Jmeter remote startup function, a windows machine is used as a controller to remotely control other windows or linux presses, so that the pressure is distributed to multiple machines to achieve high concurrency, and the test results are collected on master.

Jmeter distributed principle

II. Jmeter distributed principle

Jmeter's distributed control, to put it more popularly, refers to the remote startup function, as shown in the following figure:

1. The client machine (window system) acts as a controller controller to control the operation of multiple slave machines.

2. It is best to install the same version of jdk and jmeter on Controller and slave machines, and configure the environment variables. The installation and configuration method is similar to the windows environment.

3. Controller starts the slave machine through the GUI interface, sends the jmeter stress test script to each startup slave,slave to get the script and starts execution. Slave does not need to store scripts in advance locally, but requires dependent files (such as csv files, etc.) in the script.

4. After the execution of each slave is completed, the results are sent back to controller,controller for collection and integrated display.

Jmeter distributed configuration

III. Jmeter distributed (remote startup) configuration

1. Slave remote machine configuration

The slave remote machine needs to install jdk and jmeter, which is best consistent with the version on controller. If it cannot be satisfied, at least ensure that the jmeter on slave can run normally (for example, jmeter3.0 will need jdk1.7 or above later).

Start the jmeter-server of the salt machine

Execute the. / jmeter-server command under the% JMETER_HOME%bin directory of slave to start the jmeter service, as shown below:

Modify the default port of slave jmeter

The ip in the red box above is the ip address of the slave machine, and the port number port in the red box is the port that starts the jmeter service listening. There is usually a default port number of 1099, but it is best to customize it to ensure that the port numbers do not conflict. The modification method is as follows:

Find jmeter.properties in the% JMETER_HOME%bin directory of the slave machine, and modify server_port and server.rmi.localport in the file to customize the port number:

Server_port=1029

Server.rmi.localport=1029

Note that these two items must be modified at the same time, and the same.

After the modification, execute the jmeter-server of slave to see whether the modification takes effect in the console message.

2. Controller configuration of the control machine

To ensure that the execution command can be sent to the remote slave machine on the control machine, it is necessary to configure the ip address and port of the remote machine on the control machine.

Under the bin folder of the console jmeter installation directory, find jmeter.properties, and modify the configuration as shown in the figure below, where ip and port are the ip and port of the previous step slave, as shown in the red box when jmeter-server starts in the figure above. The configuration of multiple slave machines can be separated by commas.

Remote_hosts=10.165.124.6:1029

To add multiple slave machines, repeat the above steps.

3. Start and stop remotely

After the configuration is completed, open the GUI interface of the controller jmeter, and you can see the slave machine configured by yourself in the run-remote boot.

Add a script and click remote startup to start the slave machine. At this time, the console information can be seen on the slave machine, and the execution results can be seen on the control machine through the listener-aggregate report or looking at the result tree.

Similarly, you can also perform a remote stop operation:

Issues to pay attention to:

1. After modifying the configuration file, you must restart jmeter to take effect.

2. Before starting remotely on the control machine, you must run the jmeter-server.bat of the slave machine

3. When the jmeter script needs to rely on data files such as csv, the file needs to be uploaded to the Slave machine and the correct path needs to be set.

4. After configuring one slave machine successfully, configure multiple slave machines in turn

5. When the slave machine is a linux system, generally only one slave machine can be configured, unless the concurrency is very large, it is necessary to configure multiple slaves.

6. In distributed runtime, the total concurrency is the number of threads * the number of slave machines set in the script. If the number of threads is set to 10 and 3 slave machines are used to run, the total concurrency number is 30.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.