我环顾四周，根本找不到输出的详细解释。 大部分确实容易理解，但有一部分让我感到困惑：
Time per request: 109537.505 [ms] (mean) Time per request: 109.538 [ms] (mean, across all concurrent requests) 这意味着对我来说，如果你测量所有的并发请求（不pipe是什么意思），那么请求突然返回100倍。 为什么每个请求的时间会有所改变？ 这没有任何意义。
有没有这个ab输出的其他部分的详细解释？
如果将并发性设置为1，则这两者之间没有区别 。 当你有多个请求同时执行时，它开始变得重要。
我们来看看我在localhost上得到的一个例子：
ab -c 1 -n 1000 http://localhost/
会给：
Time taken for tests: 3.912 seconds Time per request: 3.912 [ms] (mean) Time per request: 3.912 [ms] (mean, across all concurrent requests)
这意味着需要3.912秒来逐个执行1000个请求。 所以单个请求平均需要3.912秒/ 1000 = 3.912毫秒。
现在让我们来看看并发级别：
ab -c 10 -n 1000 http://localhost/
Time taken for tests: 0.730 seconds Time per request: 7.303 [ms] (mean) Time per request: 0.730 [ms] (mean, across all concurrent requests)
这一次，而不是3.912秒，我们只需要0.730秒，完成工作。 我们已经在0.730秒内完成了1000个请求，所以一个请求平均需要0.730秒/ 1000 = 0.730 ms（最后一行）。 但情况有些不同，因为我们现在同时执行10个请求。 所以实际上我们这里的电话号码并没有反映一个请求完成的实际时间 。 0.730ms * 10（并发请求数）= 7.303ms。 如果一个请求的完成是非并发的（或者更正确地说，在当前的并发级别以孤立的方式执行），那么这个时间平均需要花费时间。
你看到的最后一个数字（0.730 ms）用来告诉大概如果你用当前并发级别-c 10 （至less理论上是这样）添加了1个请求（ -n 1001 ），那么总的时间会增加多less。
7.303毫秒给你一个单独的请求将运行多长时间的概述。
您在示例-c 1和-c 10之间看到的更改：
[-c 1 ]: Time per request: 3.912 [ms] (mean) [-c 10]: Time per request: 7.303 [ms] (mean)
意味着如果一个请求是唯一正在执行的请求，它的运行速度会更快。 如果有多个请求-c 10竞争资源，则单个请求将花费较长的时间完成。 但是，如果考虑到您同时执行10个这样的请求的事实，在这个7.303毫秒中，您处理了10个请求，而不是1个。
因此，作为一个请求延迟的措施 – 7.303毫秒更有用。 但作为衡量performance – 0.730毫秒更有意义。 实际上，如果您允许10个并发请求，则0.730 ms <3.912 ms，您将看到您将能够每秒聚合更多的请求。