我应该如何解释 Apache 的 ab 基准测试工具的结果？

Posted 2023-02-23

技术标签:

【中文标题】我应该如何解释 Apache 的 ab 基准测试工具的结果？【英文标题】：How am I supposed to interpret the results from Apache's ab benchmarking tool? 【发布时间】：2011-06-19 08:36:28 【问题描述】：

好的，我到处搜索，但似乎无法在网上找到详细的资源来解释如何解释 Apache 的 ab 服务器基准测试工具的结果。我用我认为完全不同的参数运行了几次测试，但看到了非常相似的结果（我很难认为这意味着我的网站正在完美地扩展！）。如果有人可以向我指出详细的资源，关于如何理解此测试的结果，或者如果有人想在这里创建一个，我认为这对我和其他人非常有用。

【问题讨论】：

【参考方案1】：

令人沮丧，不是吗？我正在尝试做同样的事情，看看我新配置和配置的专用服务器与其他服务器相比如何。

我最终要做的是将我当前的生产服务器（双核 4GB RAM）与新服务器（四核 8GB RAM）进行比较。

我需要通过并排比较来“玩得很好”，因为生产服务器是实时的，我不想为我的用户“破坏”服务器。

在只调用 phpinfo() 的 php 页面上使用以下命令比较当前与新的：ab -kc 20 -t 60

在我当前的生产服务器上，我看到如下内容，它无法在给定的时间内完成任务：

Time taken for tests:   60.1234 seconds
Complete requests:  24538
Failed requests:    58
(Connect: 0, Length:    58, Exceptions: 0)
Requests per second:    408.96 [#/sec] (mean)
Time per request:   48.905 [ms] (mean)
Time per request:   2.445 [ms] (mean, across all concurrent requests)

VS 在新服务器上以一半的时间完成所有测试的以下内容：

Time taken for tests:   29.838791 seconds
Complete requests:  50000
Failed requests:    11
(Connect: 0, Length:    11, Exceptions: 0)
Requests per second:    1675.67 [#/sec] (mean)
Time per request:   11.936 [ms] (mean)
Time per request:   0.597 [ms] (mean, across all concurrent requests)

现在，这并不是一个真正的“公平”测试，因为除了基准测试之外，当前服务器还处理 20 个网站。另外，它实际上只是在测试 apache 和 php。

对我的一个更复杂的主页进行相同的测试，在当前服务器上“感觉”很慢，我看到以下内容：当前服务器：

Time taken for tests:   60.14170 seconds
Complete requests:  510
Requests per second:    8.50 [#/sec] (mean)
Time per request:   2353.497 [ms] (mean)
Time per request:   117.675 [ms] (mean, across all concurrent requests)

新服务器：

Time taken for tests:   60.18651 seconds
Complete requests:  1974
Requests per second:    32.89 [#/sec] (mean)
Time per request:   608.092 [ms] (mean)
Time per request:   30.405 [ms] (mean, across all concurrent requests)

此测试正在加载 Joomla CMS 动态生成的页面。这更像是一个“现实世界”的测试。同样，由于新服务器不处理当前站点流量，因此这不是苹果对苹果的比较。我不想更努力地进行测试，否则我会冒着最终用户在我的网站上的体验的风险。

将网站迁移到新服务器后，我计划再次进行上述测试，以便了解我的常规网站流量对基准测试有何影响。同一台机器的生产与闲置基准测试结果。

现在，我也在考虑给新服务器施加压力，并确保它反应良好。运行命令 ab -n 50000 -c 200 我正在查看 top 命令并查看使用了多少 CPU 和内存，同时还 *f5*在我的浏览器中查看页面是否有任何错误，并了解服务器响应需要多长时间。

我的第一次测试给了我：

Concurrency Level:  200
Time taken for tests:   692.160011 seconds
Complete requests:  50000
Failed requests:    30102
(Connect: 0, Length:    30102, Exceptions: 0)
Write errors:   0
Non-2xx responses:  30102
Total transferred:  456568770 bytes
html transferred:   442928962 bytes
Requests per second:    72.24 [#/sec] (mean)
Time per request:   2768.640 [ms] (mean)
Time per request:   13.843 [ms] (mean, across all concurrent requests)
Transfer rate:  644.17 [Kbytes/sec] received

请注意非常高的失败请求率。我的 apache 设置为最多 250 个同时请求，但我的 mysql 只有 175 个。这里的故障点是 MySQL。它无法处理来自 apache 的所有请求。我的网页浏览器页面加载在多次页面刷新时给了我一个 MySQL 连接错误页面。

所以，我将 MySQL 提高到 300 个并发请求（我已经这样做了，但忘记重新启动 MySQL，所以这是一个很好的测试 - 我发现了一个需要的更改，并且不小心做了一个经验测试验证更改的必要性）。

下一次运行给了我以下结果：

Concurrency Level:      200
Time taken for tests:   1399.999463 seconds
Complete requests:      50000
Failed requests:        5054
   (Connect: 0, Length: 5054, Exceptions: 0)
Write errors:           0
Non-2xx responses:      5054
Total transferred:      1016767290 bytes
HTML transferred:       995713274 bytes
Requests per second:    35.71 [#/sec] (mean)
Time per request:       5599.998 [ms] (mean)
Time per request:       28.000 [ms] (mean, across all concurrent requests)
Transfer rate:          709.24 [Kbytes/sec] received

这花费了两倍的时间，但失败的请求率要低得多。基本上，服务器现在配置为能够处理我网站主页之一的至少 200 个同时页面视图，但为它们提供一个页面需要 5 秒。不是很好，但比我之前遇到的 MySQL 错误要好得多。

在所有这些过程中，我的服务器 CPU 使用率一直保持在 100%，“平均负载”徘徊在 180 以上。MySQL 使用了大约 8-9% 的 CPU，并且没有使用太多的 RAM。我已经分配了它，因为我只是反复敲击同一个页面，所以它只处理一个数据库。配置为增长到的 4GB+ 中的 400MB。 top 显示缓冲区和缓存的内存使用量大约占总可用 RAM 的 50%。所以当我用这个测试加载机器时，它并没有接近过载点。在真实世界的数据库使用情况下，MySQL 应该会占用我分配给它的大部分内存，因此此时服务器应该非常接近满负荷。

我的下一个测试是在 250 个连接的“满负载”下测试 apacheab -n 50000 -c 250

Concurrency Level:      250
Time taken for tests:   1442.515514 seconds
Complete requests:      50000
Failed requests:        3509
   (Connect: 0, Length: 3509, Exceptions: 0)
Write errors:           0
Non-2xx responses:      3509
Total transferred:      1051321215 bytes
HTML transferred:       1029809879 bytes
Requests per second:    34.66 [#/sec] (mean)
Time per request:       7212.577 [ms] (mean)
Time per request:       28.850 [ms] (mean, across all concurrent requests)
Transfer rate:          711.73 [Kbytes/sec] received

这显示了与使用适当的 MySQL 连接上限的 200 连接测试类似的结果。我觉得这对我很好。我不喜欢返回页面的 7 秒，但我认为我可以通过在 Joomla 中启用缓存来改进 Joomla 级别，无论是使用 APC 还是 Memcache，它们都已安装但 Joomla 尚未使用。

为了碰碰运气，我想我会尝试 300 个同时连接。 ab -n 50000 -c 300 浏览器显示快速页面加载需要长时间等待。否则，结果不会有太大变化。

Concurrency Level:      300
Time taken for tests:   1478.35890 seconds
Complete requests:      50000
Failed requests:        2266
   (Connect: 0, Length: 2266, Exceptions: 0)
Write errors:           0
Non-2xx responses:      2266
Total transferred:      1079120910 bytes
HTML transferred:       1057241646 bytes
Requests per second:    33.83 [#/sec] (mean)
Time per request:       8868.215 [ms] (mean)
Time per request:       29.561 [ms] (mean, across all concurrent requests)
Transfer rate:          712.99 [Kbytes/sec] received

我不知道我对这些结果的解释是否“正确”，或者我是否遗漏了一些有价值的东西，但由于缺乏我能找到的指导，这就是我想出的。

我只是使用结果来确保我获得了良好的响应率 - 缺乏完美的响应率让我很担心，但我不知道如何以我可以检查的方式查看或重现故障。

每个请求的缓慢时间也让我担心，但我认为我可以在应用层解决大部分问题。

我相信，虽然服务器会慢到爬行，但它可以处理重负载情况。

在这些基准测试之后查看其他性能调整工具（如 MonYog）也表明我当前的配置“足够好”。

我希望有人发布测试结果的地方，我可以通过硬件描述和软件配置进行复制，这样我就知道我是否“有竞争力”，或者我是否还有很多工作要做才能最好地利用我的设备。因此，我为什么要发布我的结果。

【讨论】：

我认为您可能误解了失败的请求行，另请参阅我的回答。感谢 amarillion 的澄清你是在本地机器上测试ab吗？即 - 您在 Web 服务器所在的同一台机器上做 AB。当我在自己的计算机上执行 apache 基准测试时，我每秒只能收到超过 1k 个请求。我倾向于在本地使用 AB 进行调优。诚然，这不是一个真正的测试，但通常很少有人可以“调整”互联网连接（有些事情可以做，但超出了这个问题的范围）。如果网络是限制因素，并且您可以调整超出网络所能提供的范围，那么您基本上已经根据需要优化了系统。【参考方案2】：

请注意，对于“失败的请求”行，失败的请求是通过比较后续请求的长度来确定的。对于动态网站，这并不一定意味着请求完全失败！所以不要担心失败的请求行。

另请参阅：http://www.celebrazio.net/tech/unix/apache_bench.html

【讨论】：

【参考方案3】：

顺便说一句，AB 是单线程的（这对于像 2001 Pentium 4 这样的旧单核 CPU 来说是可以的）。

要测试托管 Web 服务器的多核 CPU（nginx/Lighty 使用多个进程，Apache 使用多个线程），您应该使用 Weighttp（与 AB 兼容）。

“Weighttp -t 6”将运行 6 个客户端线程（相比之下，“AB -t 6”将运行 6 秒测试）。

通过使用多个客户端线程（与 Webserver 工作线程的数量一样多 - 这应该与服务器盒的 CPU 内核数量相匹配），您将获得更多相关的结果。

【讨论】：

ab 允许您指定并发级别。我认为这意味着它是多线程的，就您在这里使用的意义而言。例如。 ab -n 1000 -c 10 myserver 将运行来自 10 个并发请求者的 100 个请求，总共获得 1000 个命中。 @Rick-777 似乎ab 等待第一批请求完成，然后再发送第二批。所以在发出请求的意义上不是多线程的？还有requester是什么意思？ ab的源码我没有研究过，所以只报告了它的options。对于请求者，我只是指一个非常一般意义上的线程（并非所有线程都相同）。【参考方案4】：

在 creuzerm 答案之上。这是一个非常好的链接，其中包含更多信息

https://serverfault.com/questions/274252/apache-ab-please-explain-the-output

更多关于行之间的差异

Time per request:       7.303 [ms] (mean)
Time per request:       0.730 [ms] (mean, across all concurrent requests)

【讨论】：

【参考方案5】：

Time per request:       7.303 [ms] (mean)
Time per request:       0.730 [ms] (mean, across all concurrent requests)

第一个与每个并发用户的平均请求时间有关，因此如果您对 1000 个请求和 200 个并发用户进行测试，第一个将是每个 200 个请求的平均时间。第二个与整体请求时间有关，即整个 1000 个请求的平均时间

【讨论】：

以上是关于我应该如何解释 Apache 的 ab 基准测试工具的结果？的主要内容，如果未能解决你的问题，请参考以下文章

Apache HTTP server benchmarking tool(ab)-服务器基准测试工具一文上手

如何使用，判断Apache AB压力测试

如何使用Apache的ab工具进行网站性能测试

对具有许多同时请求的 django 应用程序进行基准测试，例如 ab

如何使用Apache的ab工具进行网站性能测试

轻量级压测工具Apache Bench实战