Introduction to wrk
wrk is a modern HTTP benchmarking tool capable of generating significant load on a single multi-core CPU. It adopts a multi-threaded design and uses extensible event notification mechanisms like epoll and kqueue. In addition, users can specify LuaJIT scripts to complete functions such as HTTP request generation, response processing and custom reporting.
wrk official website
wrk install
wrk supports linux installation, but does not support windows installation. So we can only install it in the linux environment
installation steps
1. Download wrk
git clone https://github.com/wg/wrk
2. Switch to the wrk directory, compile and install
cd wrk
make
3. Copy the executable file wrk to /usr/local/bin
cp wrk /usr/local/bin
Introduction to wrk parameters
input the command
wrk --help
View supported related parameters
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)
- -c The number of TCP connections established and maintained with the server is actually the number of concurrency
- -d The duration of the pressure test (in seconds), the default is 10s
- -t The number of threads for pressure testing. The normal setting is 2-4 times the number of CPU core threads. If there are too many threads, the stress test effect will be affected due to frequent thread context switching
- -s specifies the Lua script path. Complex requests can be implemented through Lua scripts
- -H specifies the HTTP Header of the request
- –latency After the pressure test is over, print the response time statistics message
- –timeout request timeout
- -v version information
example of using wrk
Preconditions for using wrk
Before the pressure test, make sure that the maximum number of file handles in Linux is sufficient, you can pass
ulimit -a
View the current user's file handle limit, if not enough, it will report
"too many open files"
You can modify
the content of the /etc/security/limits.conf file, and the modified content can be as follows
root soft nproc 65535
root hard nproc 65535
root soft nofile 65535
root hard nofile 65535
At this time, check it again through ulimit -a. If it does not take effect, you can modify it in the /etc/security/limits.d/ directory. After checking the information, in the Centos7 system, Systemd is used to replace the previous SysV. The configuration scope of the /etc/security/limits.conf file has been reduced. The configuration of /etc/security/limits.conf is only applicable to the resource limit of users who log in through PAM authentication, and it does not take effect on the resource limit of systemd's service.
So we can create a new file such as nofile.conf in /etc/security/limits.d/, fill in
root soft nproc 65535
root hard nproc 65535
root soft nofile 65535
root hard nofile 65535
Then execute the restart command
example
wrk -t32 -c5000 -d60s --timeout 30s --latency https://www.baidu.com/
The meaning of this command is to use 32 threads to simulate 5000 concurrency, and conduct a pressure test on the Baidu website for 60s, and the request timeout time is 30s
Interpretation of stress test results
Running 1m test @ https://www.baidu.com/
32 threads and 5000 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 6.59s 5.02s 29.57s 79.01%
Req/Sec 5.14 4.82 36.00 83.11%
Latency Distribution
50% 4.91s
75% 8.24s
90% 13.38s
99% 25.42s
4677 requests in 1.00m, 51.98MB read
Socket errors: connect 40, read 0, write 0, timeout 27
Requests/sec: 77.82
Transfer/sec: 0.86MB
a. Thread Stats thread statistics, including response time and request time
- Latency: Response time, with average value, standard deviation, maximum value, plus or minus one standard deviation ratio.
- Req/Sec: The number of requests completed by each thread per second, also has the average value, standard deviation, maximum value, plus or minus one standard deviation ratio.
b. Latency Distribution response time distribution
- 50%: The response time for 50% is 4.91s.
- 75%: The response time for 75% is 8.24s.
- 90%: 90% response time is 13.38s
- 99%: 99% response time is 25.42s.
c、 4677 requests in 1.00m, 51.98MB read
1m total requests completed (4677) and data read (51.98MB)
d、 Socket errors: connect 40, read 0, write 0, timeout 27
For error statistics, the number of connect failure requests (40), read failure requests, write failure requests, and timeout requests (27) will be counted.
e、 Requests/sec: 77.82
77.82 requests per second (QPS)
f、 Transfer/sec: 0.86MB
Read 0.86MB data per second (TPS) on average
Summarize
This article is an introduction to wrk. wrk itself is lightweight, easy to install, and has low learning costs. You can get started in a few minutes. Utilizing the asynchronous event-driven framework, a large amount of concurrency can be squeezed out through few threads. However, wrk currently only supports single-machine stress testing and does not support multi-machine distributed stress testing, so wrk is suitable for performance benchmarking. In fact, in addition to wrk, there are also stress testing tools such as ab, jmeter, locust, LoadRunner, go-stress-testing, etc.