复习了一下ApacheBench的用法，兼谈服务性能测试的多因素问题

我最近有点关注 python web 开发，看了不少关于高性能IO库的对比评测，没怎么看明白，突然觉得自己对于 ab 的用法似乎不怎么想得起来了，于是复习了一下。

实验环境要尽量简单，要能凸显影响性能的几个因素，并能通过改变其中的单个因子再观察性能变化，来得到各因子和性能之间的关系。

服务器端 gunicorn -w 4 -k sync 执行一个只有一句 time.sleep(1) 的服务器程序，确保每次请求的服务时间不低于一秒

ab -c4 的情况下：

Concurrency Level: 4
Time taken for tests: 25.248 seconds
Complete requests: 100
Failed requests: 2
(Connect: 0, Receive: 2, Length: 0, Exceptions: 0)
Write errors: 0
Total transferred: 16000 bytes
HTML transferred: 1400 bytes
Requests per second: 3.96 [#/sec] (mean)
Time per request: 1009.932 [ms] (mean)
Time per request: 252.483 [ms] (mean, across all concurrent requests)
Transfer rate: 0.62 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 951 217.0 1009 1013

测试结果中需要注意的：

1. Time taken for tests * Concurrency Level == Time per request * Complete requests都是处理所有的请求的总耗时。
2. Time per request(mean) == Time taken for tests/Complete requests

注意：建立连接耗时最大值接近一秒。

并发数提高一倍，ab -c8 的情况下：

Concurrency Level: 8
Time taken for tests: 25.114 seconds
Complete requests: 100
Failed requests: 11
(Connect: 0, Receive: 11, Length: 0, Exceptions: 0)
Write errors: 2
Total transferred: 16000 bytes
HTML transferred: 1400 bytes
Requests per second: 3.98 [#/sec] (mean)
Time per request: 2009.158 [ms] (mean)
Time per request: 251.145 [ms] (mean, across all concurrent requests)
Transfer rate: 0.62 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1507 756.6 2005 2015

需要注意的是：

1. Time per request 翻倍了，而 Time per request * Completed requests 自然也就翻倍了。而 Requests per second 并没有随着并发数的增加而提高。服务器端 sync worker 每次只能处理一个请求，在客户端并发超过服务器端 worker 数，而请求又不能快速处理完毕的情况下，会造成请求积累，所以处理时间会变长
2. 建立连接耗时的最大值也翻倍了

服务器改用 -k eventlet 试试呢？

客户端先用四个并发：

Concurrency Level: 4
Time taken for tests: 25.097 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 16000 bytes
HTML transferred: 1400 bytes
Requests per second: 3.98 [#/sec] (mean)
Time per request: 1003.861 [ms] (mean)
Time per request: 250.965 [ms] (mean, across all concurrent requests)
Transfer rate: 0.62 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.2 0 1

注意建立连接耗时比 -k sync 时大大降低

八并发呢？

Concurrency Level: 8
Time taken for tests: 13.046 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 16000 bytes
HTML transferred: 1400 bytes
Requests per second: 7.67 [#/sec] (mean)
Time per request: 1043.689 [ms] (mean)
Time per request: 130.461 [ms] (mean, across all concurrent requests)
Transfer rate: 1.20 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.5 0 3

处理能力翻倍了；建立连接耗时依然很小

这是服务器端异步处理的好处：一个 worker 可以处理多个并发请求，也就是说目前服务器的处理能力是高于 -w 4 参数指明的 worker 数的。

我认为：

• Concurrency Level 和 Requests per second 比较接近的情况，说明服务器还没到性能极限
• ab 压力测试过程中出现大量错误，可能是服务器过载的表现
• sync 的情况下，显然并发数是不能超过 worker 数的
• async 类型的 worker，并发数和 worker 数的比例关系，和服务程序的复杂度有关，和 CPU 核数也有关