background

Small A: small B, recently adjust your interface always timeout ah, 8 seconds have not returned the result, whether there is A performance problem! B: Let me see

This kind of dialogue happens from time to time in reality. If it is not very serious, people will not pay attention to it.

Especially in some companies where the testing resources are not complete and the developers have no exposure to performance testing, this can be more difficult.

In the spirit of being responsible for what we write, we should all perform a simple stress test on our interfaces before we go live.

In fact, this step is also to let us have a degree, have a bottom, not to say that even can bear how much do not know. If you don’t know anything, it’s very easy to fall into a bottomless pit, which is a very scary thing.

Lao Huang usually uses Apache Bench. Of course, Jmeter, WRK and Vegeta are also very good.

Talk about the reason to use this, free installation, green version, out of the box (decompression) use, to put it bluntly, huang is actually lazy ghost ~~

Jmeter to install JDK, too lazy to do.

WRK/WRK2 is compiled by itself and can be installed directly on the MAC, but my MAC configuration is not high enough.

Vegeta is not very comfortable to use, and we will excavate it slowly later.

Apache Bench is introduced

Apache Bench is a web stress test tool of Apache server, abbreviated as AB.

Ab is a command line tool, which has low requirements on the host to initiate load. According to the ab command, you can create many concurrent access threads to simulate multiple visitors accessing a URL address at the same time. Therefore, it can be used to test the load pressure of the target server. In general, THE AB tool is small and simple, fast to learn, and can provide the required basic performance indicators, but without graphical results, cannot be monitored.

The essence of ab test is based on HTTP protocol, which can be understood as a black box performance test of Web server software. All data and calculation results obtained can be explained through HTTP.

Apache Bench is simple to use

The following examples are all on CentOS.

Install by using the following command,

yum -y install httpd-tools
Copy the code

Once installed, run ab-V to see the version information.

Ab-v This is ApacheBench, Version 2.3 <$Revision: 1430300 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/Copy the code

Run ab-H to see the help information.

There are a lot of help information, but also more detailed, Huang put some commonly used parameters have added annotations, convenient for everyone to view.

The two most commonly used parameters are -c and -n, as well as -t and -p for POST/PUT requests.

That’s a lot of crap. Let’s see how it’s used.

Two simple interfaces are prepared below to demonstrate this

[ApiController]
[Route("test")]
public class TestController : ControllerBase{[HttpGet]
    public string Get()= >"GET";

    [HttpPost]
    public string Post([FromBody]string value)= >value;
}
Copy the code

This interface is running in Docker (an active cloud server 2c4G). The following figure shows the specific information and the access details of the two interfaces.

Let’s press the interface for GET requests. 200 concurrent, 5000 requests.

ab -c 200 -n 5000 localhost:9000/test
Copy the code

The POST request is a bit different. To prepare the body argument, we create a post.json file in the/TMP directory, which contains a single string.

cat /tmp/post.json
"Post"
Copy the code

In the pressure command, specify content-type as application/json and the path to the data file is/TMP /post.json

Also 200 concurrent, 5000 requests.

ab -c 200 -n 5000 -T "application/json" -p /tmp/post.json localhost:9000/test
Copy the code

By now, we should not be too unfamiliar with how to pressure test, the more unfamiliar should be how to look at the results of pressure test.

Here’s an example of one of the results to illustrate what each metric means:

Kestrel # Server Hostname: localhost # Server Port: 9000 # Document Path: Document Length: 3 bytes # Concurrency Level: 200 # Concurrency taken for tests: Complete requests: 5000 # Failed requests: 0 # Write errors: 0 # Net connection write errors Total transferred: 680000 bytes # HTML transferred: Requests per second: 2095.43 [#/ SEC] (mean) # 95.446 [ms] (mean) # 0.477 [ms] (mean, across all concurrent requests) # 278.30 [Kbytes/ SEC] Received # Length of data received per second (transmission rate, unit: Connection Times (ms) min mean[+/-sd] median Max Connect: 0 3 3.7 2 20 Processing: 12 68 120.0 53 1057 Waiting: 1 67 120.1 52 1050 Total: Percentage of the requests served within a certain time (ms) 50% 55 66% 63 75% 68 80% 71 90% 77 95% 88 98% 105 99% 1012 100% 1058 (longest request)Copy the code

With so many indicators, we can focus on the following ones

  1. Requests per second
  2. Failed requests
  3. 90%, 95% and 98% response times

The first one is throughput, which is actually quite embarrassing.

The second is the number of failed requests, which should be as low as possible, preferably 0, with no failed requests. Imagine if 80 of 100 requests failed, this result would still be meaningful.

The third is response time, which shows how fast most requests are.

Some tips for doing manometry:

  • Try to increase the concurrency from low to high, so as not to set too large at the beginning. A good reference is the concurrency of the current phase line environment
  • The duration of the pressure test can be longer so that you can see more possible situations. Consider 5 minutes, 8 minutes, 15 minutes, etc
  • If possible, the machine under pressure and the machine under pressure should be independent, because there will be resources occupied during the pressure test, which may affect the interface under pressure
  • Do not only look at the results of the pressure test data, but also pay attention to the pressure of the CPU, memory and other indicators in the pressure test is normal
  • After the effect of internal pressure measurement reaches the expectation, the network factor of external network is considered, and the controllability is not strong

Distributed pressure measurement and full link pressure measurement, temporarily do not think about it, leave it to more professional people to do ~~