Pressure measuring tools

There are many pressure measurement tools, including simple AB and WRK, as well as relatively complex K6 and Jmeter, etc. Generally speaking, AS the main research and development personnel, I am still used to using AB or WRK for pressure measurement.

Regardless of the pros and cons of each tool, WRK can provide more pressure on a single machine for simple manometry needs.

WRK

WRK is more efficient than Apache Bench because it supports multi-threading, making it easier to leverage the power of a multi-core CPU, or even to fill it to capacity. WRK supports Lua scripts to provide more requirements such as parameter customization and parameter encryption, providing higher flexibility.

Pressure test preparation

Install WRK

See Wrk Github for a detailed installation tutorial, which is the most formal installation path.

Provide a service

Spring Boot

Spring Boot, for example, provides a simple API service.

    @GetMapping("/health")
    private void health(a) {}Copy the code

Of course, if you usually use Quarkus or vert. x, you can also write corresponding API.

Quarkus
    @Route(path = "/hello1", methods = HttpMethod.GET)
    @operation (description = "hello1 interface ")
    void hello1(RoutingContext ctx) {
        ctx.response().end("hello1, quarkus");
    }
Copy the code
Vert.x
router.get("/mxx").handler(req -> req.response().end("Hello, earth"));
Copy the code

Pressure test command

WRK commands are simple and can be viewed by running the following command

[root@ecs-1b4c-0002 ~]# wrk
Usage: wrk <options> <url>                            
  Options:                                            
    -c, --connections <N>  Connections to keep open   
    -d, --duration    <T>  Duration of test           
    -t, --threads     <N>  Number of threads to use   
                                                      
    -s, --script      <S>  Load Lua script file       
    -H, --header      <H>  Add header to request      
        --latency          Print latency statistics   
        --timeout     <T>  Socket/request timeout     
    -v, --version          Print version details      
                                                      
  Numeric arguments may include a SI unit (1k, 1M, 1G)
  Time arguments may include a time unit (2s, 2m, 2h)
Copy the code

Pressure test API

Use the following command to pressure test for 50 connections for 20 seconds.

wrk -c50 -d20s 'http://127.0.0.1:8088/vc/health'  --latency
Copy the code

The results are as follows:

[root@ecs-1b4c-0002 ~]# WRK c50 - d20s' http://127.0.0.1:8088/vc/health '- latency
Running 20s test50 connections @ http://127.0.0.1:8088/vc/health 2 threads and Thread Stats Avg Stdev Max + / - Stdev Latency 109.32 ms Latency Distribution 50% 93.31ms 75% 175.14ms 90% 248.54ms 99% 380.58 ms 10598 requestsin20.09 s, 1.00 MBread
Requests/sec:    527.59
Transfer/sec:     51.01KB
Copy the code

Analysis of pressure measurement results

Requests/sec

The first result we’ll probably focus on is Requests/ SEC, or Requests per second, also known as QPS.

The larger the QPS, the more requests handled per second, generally means the better our API is capable of.

10598 requests in 20.09s, 1.00MB read

This place keeps track of how many requests were processed in a total of 20 seconds. If there is an API response exception, it will also show up in this location. If the number of error requests is not told, all requests are considered to have been properly responded to.

Req/Sec 270.47 136.63 550.00 59.89%

This metric is similar to QPS because the number of requests processed per second is not constant. It is possible to process fewer requests in one second and more in the next.

This discreteness is mainly expressed in terms of variance. The smaller the variance, the more stable the service, and the smaller the fluctuation range.

Latency 109.32ms 99.16ms 666.12ms 68.08%

This is the response time. Typically we describe our performance requirements by saying, “Ensure average response time is under 250ms and ensure 99% of requests are completed within 300ms”. And again, this has the notion of variance. Ditto.

Latency Distribution

More detailed description of response time, for example we know that 90% of requests are completed in 248.58ms and 99% in 380.58ms. It obviously does not match the performance index we requested just now.

The overall analysis

As a developer, the purpose of pressure testing is to check whether the API we provide conforms to the basic indicators of the service and find possible potential problems. Generally speaking, as long as the performance requirements are met, it can be qualified.

The performance of different servers varies greatly (the better the server configuration is, the better the performance is), so we need to have certain experience to judge the indicators of the service.

For example, the above pressure test results show that the QPS of this API is relatively low. Considering business requirements and user levels, we decide that (the service meets the expectation or the performance is not up to the standard and needs to be optimized and improved).

Students who often do business stress testing may know that under the synchronous model of Spring Boot, the performance is low on the line. If b-side business is fine, but if C-side business is easy to reach the ceiling, then more knowledge about cluster, microservice, distribution and so on is needed.

Post Quarkus pressure measurement performance (same server)

[root@ecs-1b4c-0002 ~]# WRK c50 - d20s' http://127.0.0.1:8080/hello1 '- latency
Running 20s test50 connections @ http://127.0.0.1:8080/hello1 2 threads and Thread Stats Avg Stdev Max + / - Stdev Latency 537.64 us 1.61 ms 33.92ms 94.95%REq /Sec 115.20k 18.64k 168.36K 69.00% Latency Distribution 50% 162.00us 75% 318.00us 90% 720.00us 99% 8.69 ms 4592667 requestsin20.05 s, 437.99 MBread
Requests/sec: 229060.92
Transfer/sec:     21.84MB
Copy the code

​

K6

K6 is also a relatively new pressure testing tool, you can use JS to write pressure testing scripts.

See tiandao load test K6

Including stress testing, load testing, smoke testing, automated testing, etc.

​

Reference documentation

  1. Load test K6 under Tiandao
  2. Internal pressure test VS external pressure test
  3. Anything outside of a business scenario is a bully
  4. Please give Sprint Boot some more memory​

​

​

​

​