Basic introduction and experience of developing short video e-commerce Jmeter from scratch

basic

Jmeter main components

1. Test plan : it is the starting point for testing with JMeter, and it is the container for other JMeter test components

2. Thread group : represents a certain number of users, which can be used to simulate users sending requests concurrently. The actual request content is defined in the Sampler, which is contained by the thread group.

3. Configuration element : used to initialize variables for use by the sampler. Similar to the configuration file of the framework, the configuration required for parameterization is in the configuration element.

4. Preprocessor : responsible for working before the request, often used to modify the settings of the request

5. Timer : Responsible for defining the delay interval between requests. In the absence of a timer, JMeter will not pause sending requests.

6. Sampler (Sampler) : It is the smallest unit for sending requests to the server in performance testing and recording response information and response time, such as: HTTP Request Sampler, FTP Request Sample, TCP Request Sample, JDBC Request Sampler, etc., each of which is different The type sampler can send different types of requests to the server according to the set parameters, and can also use Java type requests for custom writing.

7. Post-processor : responsible for working after the request, and commonly used to obtain the returned value.

8. Assertion : It is used to judge whether the result of the request response is as expected by the user.

9. Listener : Responsible for collecting test results and determining how the results are displayed. However, graphical rendering consumes a lot of client performance and is not recommended for formal performance testing.

10. Logic controller : You can customize the behavior logic of JMeter sending requests. It can be used in conjunction with Sampler to simulate complex request sequences.

Component Execution Order

Configuration element -> preprocessor -> timer -> sampler -> postprocessor -> assertion -> listener

The basic steps for interface testing using Jmeter are as follows:

1. Test plan

2. Thread group

3. HTTP Cookie Manager

4. Http request default value

5. Sampler (HTTP request)

6. Affirmations

7. Listener (view result tree, graph result, aggregation report, etc.)

extractor

When there is a dependency between requests, for example, the input parameter of one request is the data returned by another request , then association processing is needed, and Jmeter can use some components in the post-processor to handle the association,

Commonly used association methods:

• Regular Expression Extractor - works for all returned formats

• Boundary value extractor - available for all returned formats

• Json extractor - only applicable to returned data in json format (now basically restful API, choose this)

• XPath extractor - only applicable to return data in html or xml format

Json extractor

The syntax of JsonPath is recommended for debugging on this website: http://jsonpath.com

example

{
    
    
    "data":[
        {
    
    
            "name":"张三",
            "age":18
        },
        {
    
    
            "name":"李四",
            "age":28
        }
    ]
}

To get the first person's name
JSON Path expressions:$.data[0].name

To get the name
JSON Path expressions with age >18:$.data[?(*@*.age>18)].name

boundary value extractor

For example,
view=1&token=721652512141&name=ggui
left border : token=
right border : &name
the result can be obtained 721652512141
PS: Note that the left and right borders are as unique as possible, which can more accurately match the characters you want to extract

advanced

Dynamic parameters

For POST request I used the following Jmeter function

• __UUID() – returns a unique GUID structure

{
    
    
    "project": {
    
    
        "uuid": "${__UUID()}"
    }
}

to parameterize

Three common implementations of JMeter parameterization.

• CSV Data Set Config : Put parameterized data into a file, and parameterized reading depends on file operations. Such a parameterization method is very common, especially suitable for scenarios with a large amount of parameterized data , and the maintenance is relatively simple and flexible.
• User Defined Variables : Generally speaking, you can configure public parameters in the script, such as domain name and port number, which do not need to be changed dynamically with the pressure test, which is more convenient for environment switching .
• Functions in Function Helper : Use functions to generate parameters. If you need random numbers, uuids, etc., you can use functions to generate them. JMeter also provides corresponding interfaces for secondary development and custom functions.

Context

• The boundary extractor associates the required data through the left and right boundaries;

• Json Extractor extractor, for the returned json data type;

• The regular expression extractor extracts data through regular expressions and realizes association.

Set Jmeter language to Chinese environment

1. Temporary settings

Jmeter menu bar select Options -> Choose Language -> Chinese (Simplified)

In this way, after restarting the software, it becomes the English environment again.

2. Permanent settings

Enter the apache-jmeter\bin directory, find the "jmeter.properties" file, search for and modify "language=zh_CN" in the file, save it and then open jmeter to permanently change to the Chinese environment.

Pressure testing in non-GUI mode

After deploying Jmeter on linux, upload the xxx.jmx script.

# 切换目录
cd /usr/laker/apache-jmeter-5.5/bin
# 执行脚本
./jmeter -n -t /usr/laker/apache-jmeter-5.5/go-laker.jmx -l /usr/laker/result/result.jtl -e -o /usr/laker/result/WebReport

/usr/laker/apache-jmeter-5.5/go-laker.jmx: This path is the absolute path of the Jmeter script.

/usr/laker/result/result.jtl: jtl result generated after running the script.

/usr/laker/result/WebReport: The absolute path of the html graphical report generated after running the script successfully, if you do not need this result, delete "-e -o /usr/laker/result/WebReport"

compressionzip -r archive.zip folder/

Parameter Description:

• -n: Execute JMeter in non-GUI mode

• -t: The location where the test file is executed

• -l: Specifies the save file for generating test results, such as: jtl file format, txt file format

• -e: After the test, generate a test report

• -o: Specify the storage location of the test report

Distributed stress testing

For stand-alone JMeter, it is best to control the number of threads within 1000; if it exceeds 1000 threads, it is recommended to use JMeter distributed pressure measurement, which can solve the bottleneck problem formed by the JMeter client itself to a certain extent.

The way JMeter works is that a control node initiates tests on multiple worker nodes .

• controller node

  A system running the JMeter GUI, which controls the tests

• work node

  A system running jmeter-server , which takes commands from the GUI and sends requests to the target system

• Target

  The web server we plan to stress test

important important important

• The control node, the working node, and the nodes to be stress tested need to communicate with each other through the network (try to ping each other, but be careful that the firewall blocks them)

• Control node, worker nodes use the same version of JDK and Jmeter (very important)

• Control node, jmeter.propertiesfile open configuration of working nodeserver.rmi.ssl.disable=true

• It is normal for the worker nodes to run Jmeter tests with No GUI alone.

• Add the IP address of the remote working node to the working node, and open the jmeter.properties configurationremote_hosts=192.168.0.10,192.168.0.11,192.168.0.12,192.168.0.13

• Detailed documentation: https://jmeter.apache.org/usermanual/jmeter_distributed_testing_step_by_step.htm l

1. Start a single worker node

2. Start all worker nodes

common mistakes

error log 1

[root@localhost bin]# ./jmeter-server
Server failed to start: java.rmi.RemoteException: Cannot start. localhost is a loopback address.
An error occurred: Cannot start. localhost is a loopback address.

If An error occurred: Cannot start. localhost is a loopback address error occurs when
starting. Solution : specify the starting ip

cd /usr/laker/apache-jmeter-5.5/bin
sh jmeter-server -Djava.rmi.server.hostname=x.x.x.x
# 或 nohup ./jmeter-server -Djava.rmi.server.hostname=10.22.66.10 & 

error log 2

ERROR o.a.j.e.ClientJMeterEngine: Error in rconfigure() method 
java.lang.IllegalStateException: Engine is busy - please try later
...

Solution : Make sure that the JDK and jmeter versions of the control node and all working nodes are consistent.

My above error is caused by inconsistent JDK versions.

The correct log is as follows:

Created remote object: UnicastServerRef2 [liveRef: [endpoint:[10.2.66.197:39798                                                                                       ](local),objID:[-243708a9:18831fb2c04:-7fff, -9195443886642911871]]]

Starting the test on host 10.224.76.197 @ May 19, 2023 3:09:09 AM GMT (1684465749583)
Finished the test on host 10.224.76.197 @ May 19, 2023 3:10:10 AM GMT (1684465810986)

monitor

PerfMon plug-in : monitor server hardware, such as CPU, memory, hard disk read and write speed, etc.

The monitoring indicators are as follows :

hardware monitoring

• Disk read and write speed remaining
• CPU usage size
• memory usage size
• Network read and write speed
• number of file handles

System monitoring

• application

  • GC
  • Number of connection requests, number of rejections, packet loss rate, request timeout, etc.
  • link monitoring
  • Whether the business logic is running normally under high concurrency of business monitoring
  • Threads

• database

  • slow query
  • long business

• cache

  • Connections
  • slow command
  • cache hit rate

• MQ

  • Production speed
  • consumption speed
  • message accumulation

Note which are process level and which are system level

template

• Http template
• Websocket template