好的，我到处搜索，但似乎无法在网上找到详细的资源来解释如何解释 Apache 的 ab 服务器基准测试工具的结果。我用我认为完全不同的参数运行了几次测试，但看到了非常相似的结果（我很难认为这意味着我的网站正在完美地扩展！）。如果有人可以向我指出详细的资源，关于如何理解此测试的结果，或者如果有人想在这里创建一个，我认为这对我和其他人非常有用。
【问题讨论】：
标签： apache scalability benchmarking
令人沮丧，不是吗？我正在尝试做同样的事情，看看我新配置和配置的专用服务器与其他服务器相比如何。
我最终要做的是将我当前的生产服务器（双核 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）也表明我当前的配置“足够好”。
我希望有人发布测试结果的地方，我可以通过硬件描述和软件配置进行复制，这样我就知道我是否“有竞争力”，或者我是否还有很多工作要做才能最好地利用我的设备。因此，我为什么要发布我的结果。
【讨论】：
请注意，对于“失败的请求”行，失败的请求是通过比较后续请求的长度来确定的。对于动态网站，这并不一定意味着请求完全失败！所以不要担心失败的请求行。
【讨论】：
顺便说一句，AB 是单线程的（这对于像 2001 Pentium 4 这样的旧单核 CPU 来说是可以的）。
要测试托管 Web 服务器的多核 CPU（Nginx/Lighty 使用多个进程，Apache 使用多个线程），您应该使用 Weighttp（与 AB 兼容）。
“Weighttp -t 6”将运行 6 个客户端线程（相比之下，“AB -t 6”将运行 6 秒测试）。
通过使用多个客户端线程（与 Webserver 工作线程的数量一样多 - 这应该与服务器盒的 CPU 内核数量相匹配），您将获得更多相关的结果。
【讨论】：
ab 等待第一批请求完成，然后再发送第二批。所以在发出请求的意义上不是多线程的？还有requester是什么意思？
ab的源码我没有研究过，所以只报告了它的options。对于请求者，我只是指一个非常一般意义上的线程（并非所有线程都相同）。
在 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)
【讨论】：
Time per request: 7.303 [ms] (mean)
Time per request: 0.730 [ms] (mean, across all concurrent requests)
第一个与每个并发用户的平均请求时间有关，因此如果您对 1000 个请求和 200 个并发用户进行测试，第一个将是每个 200 个请求的平均时间。 第二个与整体请求时间有关，即整个 1000 个请求的平均时间
【讨论】：