我应该如何解释 Apache ab 基准测试工具的结果？
好吧，我已经到处搜索了，但我似乎无法在网上找到详细的资源来了解如何解释 Apache 的 ab 服务器基准测试工具的结果。我已经使用我认为截然不同的参数进行了多次测试，但看到了非常相似的结果（我很难认为这意味着我的网站正在完美扩展！）。如果有人可以向我指出关于如何理解此测试结果的详细资源，或者如果有人想在这里创建一个资源，我认为这对我和其他人都非常有用。
Alright, I've searched everywhere and I can't seem to find a detailed resource online for how to interpret the results from Apache's ab server benchmarking tool. I've run several tests with what I thought were drastically different parameters, but have seen very similar results (I have a hard time thinking that this means my site is scaling perfectly!). If there is a detailed resource someone could point me to, on how to understand the results from this test, or if someone feels like creating one here, I think that would be very useful to me and others.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
令人沮丧，不是吗？我正在尝试做同样的事情，看看我新配置和配置的专用服务器与其他服务器相比如何。
我最终要做的是将我当前的生产服务器（双核 4GB RAM）与新服务器（四核 8GB RAM）进行比较。
我需要“好好地”进行并排比较，因为生产服务器是实时的，我不想为我的用户“破坏”服务器。
在仅调用 phpinfo() 的 php 页面上将当前命令与新命令进行比较： ab -kc 20 -t 60
在我当前的生产服务器上，我看到类似以下内容，但它无法未在给定时间内完成任务：
与新服务器上的以下内容相比，新服务器仅用了一半的时间完成了所有测试：
现在，这并不是一个真正的“公平”测试，因为当前服务器正在处理除了基准测试之外还有 20 个网站。另外，它实际上只是测试 apache & php。
对我的一个更复杂的主页（在当前服务器上“感觉”缓慢）进行相同的测试，我看到以下内容：
当前服务器：
新服务器：
此测试正在加载 Joomla CMS 动态生成的页面。这更像是一个“现实世界”的测试。同样，由于新服务器不处理当前站点流量，因此这不是同类比较。我不想进行更加严格的测试，否则我会拿我的最终用户在我的网站上的体验冒险。
将网站迁移到新服务器后，我计划再次进行上述测试，以便了解我的常规网站流量对基准测试有何影响。同一台机器的生产与闲置基准测试结果。
现在，我也在考虑对新服务器施加压力并确保其反应良好。
运行命令 ab -n 50000 -c 200 我正在观察 top 命令并查看有多少 CPU 和内存。正在使用内存，同时还在浏览器中 *f5* 浏览页面，以查看是否出现任何错误，并了解服务器响应所需的时间。
我的第一次测试给了我：
请注意非常高的失败请求率。我的 apache 设置为最多 250 个并发请求，但我的 MySQL 仅为 175 个。MySQL 是这里的故障点。它无法处理来自 apache 的所有请求。我的网络浏览器页面加载在多次页面刷新时都会出现 MySQL 连接错误页面。
因此，我将 MySQL 的并发请求数提高到 300 个（我已经做到了，但忘记重新启动 MySQL，所以这证明是一个很好的测试 - 我已经确定了所需的更改，并且意外地进行了验证更改的实证测试）必要性）。
下一次运行给了我以下结果：
这花费了两倍的时间，但失败的请求率要低得多。基本上，服务器现在配置为能够处理我网站主页之一的至少 200 个同时页面视图，但每个页面需要 5 秒才能为它们提供服务。不是很好，但比我之前遇到的 MySQL 错误要好得多。
在所有这些过程中，我的服务器 CPU 使用率一直保持在 100%，“平均负载”徘徊在 180 以上。MySQL 使用了大约 8-9% 的 CPU，并且没有使用我分配给它的太多 RAM ，因为我只是反复敲击同一页面，所以它只处理单个数据库。配置可增长到 4GB+ 中的 400MB。 顶部 显示缓冲区和缓存内存的使用情况，大约占总可用 RAM 的 50%。因此，当我对机器进行加载测试时，它并没有接近过载点。在真实的数据库使用情况下，MySQL 应该会占用我分配给它的大部分内存，因此服务器此时应该非常接近满负载。
我的下一个测试是在 250 个连接的“满负载”下测试 apache ab -n 50000 -c 250
这显示了与使用适当的 MySQL 连接上限的 200 个连接测试类似的结果。我想这对我来说很好。我不喜欢 7 秒返回页面，但我认为我可以通过使用 APC 或 Memcache 在 Joomla 中启用缓存来改进 Joomla 级别，APC 或 Memcache 都已安装但尚未被 Joomla 使用。
为了碰碰运气，我想尝试 300 个并发连接。 ab -n 50000 -c 300 浏览器显示快速页面加载需要很长时间的等待。否则，结果不会有太大变化。
我不知道我对这些结果的解释是否“正确”，或者我是否遗漏了一些有价值的东西，但由于缺乏我能找到的指导，这就是我想出的结果。
我只是使用结果来确保我获得了良好的响应率 - 缺乏完美的响应率让我感到担忧，但我不知道如何以我可以检查它们的方式查看或重现失败。
每个请求的缓慢时间也让我担心，但我认为我可以在应用程序层解决其中的大部分问题。
我相信，虽然服务器速度会慢得像爬行一样，但它可以处理重负载的情况。
在这些基准测试之后查看其他性能调优工具（例如 MonYog）也表明我当前的配置“足够好”。
我希望有一个地方，人们可以发布测试结果，我可以用硬件描述和软件配置来重现，这样我就知道我是否具有“竞争力”，或者我是否还有很多工作要做才能最好地利用我的设备。因此，这就是我发布结果的原因。
Frustrating, isn't it? I am trying to do the same thing, see how my newly provisioned and configured dedicated server compares to others.
What I am ending up doing is comparing my current production server (Dual core 4GB RAM) to the new server (Quad core 8GB RAM).
I need to 'play nice' with my side by side comparisons, as the production server is live and I don't want to 'break' the server for my users.
Comparing the current vs new with the following command on a php page that just calls phpinfo(): ab -kc 20 -t 60
On my current production server, I see something like the following, where it couldn't complete the task in the given amount of time:
VS the following on the new server which completed all the tests in half the amount of time:
Now, this isn't really a 'fair' test, as the current server is handling 20 websites in addition to the benchmark test. Also, it is really only testing apache & php.
Putting this same test against one of my more complex home pages, one that 'feels' slow on the current server, I see the following:
Current Server:
New Server:
This test is loading a Joomla CMS dynamically generated page. It is a bit more of a 'real world' test. Again, with the new server not dealing with current site traffic, so it's not an apples to apples comparison. I don't want to test much harder or I risk my end user's experience on my sites.
After migrating the sites to the new server, I plan on doing the above tests again so I can see what affect my regular site traffic has on the benchmarking. The same machine's production vs idle benchmark results.
Now, I am also looking at stressing the new server out and making sure that it reacts well.
Running the command ab -n 50000 -c 200 I am watching the top command and seeing how much CPU & memory are being used while also *f5*ing the page in my browser to see if I get any errors and also to get a feel for how long it takes the server to respond.
My first test gave me:
Note the very high failed request rate. My apache is set to a max of 250 simultaneous requests, but my MySQL was at only 175. MySQL was the failure point here. It couldn't processes all the requests coming from apache. My web browser page loads was giving me a MySQL connection error page on many page refreshes.
So, I bumped up MySQL to 300 simultaneous requests (I had done it already, but had forgotten to restart MySQL, so this turned out to be a good test - I had identified a needed change, and accidentally did an empirical test validating the change's necessity).
The next run gave me the following results:
This took over twice as long, but the failed requests rate was much much lower. Basically, the server is now configured to be able to handle at least 200 simultaneous page views of one of my site's home page, but it will take 5 seconds a page to serve them. Not great, but much better than the MySQL errors I was getting previously.
During all of this, my server CPU usage is pegging at 100% with the 'load average' hovering upwards of 180. MySQL is using about 8-9% of the CPU and isn't using much of the RAM I've alloted it, as I am just repeatedly hammering the same page, so it's only dealing with a single database. 400MB of the 4GB+ it is configured to grow into. top shows the buffers and cached memory usage at about 50% of the total available RAM. So while I am loading the machine up with this test, it's not getting near the overloaded point. Under a real world database usage, MySQL should grab much of the memory I've alloted it, so the server should be pretty close to full load at that point.
My next test was to test apache at the 'full load' of 250 connections ab -n 50000 -c 250
This is showing similar results to the 200 connection test with the proper MySQL connection cap. This is good to me I think. I don't like the 7 seconds to return a page, but I think I can improve that at the Joomla level by enabling cacheing in Joomla either with APC or Memcache which are both installed but not utilized by Joomla yet.
Trying to push my luck, I thought I would try 300 simultaneous connections. ab -n 50000 -c 300 The browser shows a long wait for a quick page load. Otherwise, not really much change in the results.
I don't know if my interpretation of these results are 'right' or if I am missing something valueable, but with the lack of instruction that I could find, this is what I came up with.
I just used the results to make sure that I got a good response rate - the lack of a perfect response rate concerns me, but I don't know how to see or reproduce the failures in a way I can inspect them.
The slow time per request also concerns me, but I think I can address much of that at the application layer.
I am confident that while the server would slow to a crawl, it could handle a heavy load situation.
Looking at other performance tuning tools like MonYog after these benchmarking tests has also shown me that my current configurations are 'good enough'.
I wish there was a place where people have posted results of tests I can reproduce with a hardware description and software configs so I know if I am 'competitive' or if I have a lot of work to do yet to best utilize my equipment. Thus, why I am posting my results.
请注意，对于“失败的请求”行，失败的请求是通过比较后续请求的长度来确定的。对于动态网站，这并不一定意味着请求根本失败！所以不用担心请求行失败。
另请参阅：http://www.celebrazio.net/tech/unix/apache_bench.html< /a>
Please note that for the "failed requests" line, a failed request is determined by comparing the length of subsequential requests against each other. For dynamic website, this doesn't have to mean that the request failed at all! So don't worry about the failed request line.
See also: http://www.celebrazio.net/tech/unix/apache_bench.html
在 creuzerm 答案之上。这是一个非常好的链接，其中包含更多信息
https://serverfault.com/questions/ 274252/apache-ab-please-explain-the-output
关注更多行之间的差异
On top of creuzerm answer. Here is a very good link with some more info
https://serverfault.com/questions/274252/apache-ab-please-explain-the-output
Concerning more about the difference between lines
第一个与每个并发用户的平均请求时间有关，因此如果您要对 1000 个请求和 200 个并发用户进行测试，第一个将是每个 200 个请求的平均时间。
第二个与总体请求时间有关，即全部 1000 个请求的平均时间
the first one is related to the average time for request per concurrent users so if you are making the test for 1000 requests and 200 concurrent users, the first one will be the average time for each 200 request.
the second one is related to the overall request time which is average time over the whole 1000 requests
顺便说一句，AB 是单线程的（这对于旧的单核 CPU，如 2001 Pentium 4 来说是可以的）。
要测试托管 Web 服务器的多核 CPU（Nginx/Lighty 使用多个进程，Apache 使用多个线程），您应该使用 Weighttp（与 AB 兼容）。
“Weighttp -t 6”将运行 6 个客户端线程（相比之下，“AB -t 6”将运行 6 秒的测试）。
通过使用多个客户端线程（与 Web 服务器工作线程的数量一样多 - 应与服务器的 CPU 核心数量相匹配），您将获得更多相关结果。
On a side note, AB is single-threaded (which is OK for old single-Core CPUs like the 2001 Pentium 4).
To test a multi-Core CPU hosting a Web server (Nginx/Lighty using several processes, Apache using several threads), you should rather use Weighttp (which is compatible with AB).
"Weighttp -t 6" will run 6 client threads (by contrast "AB -t 6" would run a 6-second test).
You will get much more relevant results by using several client threads (as many as the number of Webserver workers - which should match the number of CPU Cores of the server box).