使用 AB 进行负载测试...假失败请求（长度）
为了进行一些负载测试，出于我自己的好奇心，我在我的服务器上运行：
ab -kc 50 -t 200 http://localhost/index.php
这会打开 50 个保持活动连接 200 秒，并且只是通过对 index.php 的请求来猛烈攻击我的服务器
在我的结果中，我得到：
Concurrency Level: 50
Time taken for tests: 200.007 seconds
Complete requests: 33106
Failed requests: 32951
(Connect: 0, Receive: 0, Length: 32951, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 1948268960 bytes
HTML transferred: 1938001392 bytes
Requests per second: 165.52 [#/sec] (mean)
Time per request: 302.071 [ms] (mean)
Time per request: 6.041 [ms] (mean, across all concurrent requests)
Transfer rate: 9512.69 [Kbytes/sec] received
注意 32951 "失败”的请求。 我无法弄清楚这一点。
在测试运行时，我能够从家用计算机完美访问我的网站，尽管页面底部的页面加载时间报告为 0.5，而不是通常的 0.02。 然而我从来没有遇到过失败的请求。
那么为什么 AB 报告一半的连接失败呢？ 在这种情况下，“长度：”是什么意思？
To do some load testing, for my own curiosity, on my server I ran:
ab -kc 50 -t 200 http://localhost/index.php
This opens up 50 keep-alive connections for 200 seconds and just slams my server with requests for index.php
In my results, I get:
Concurrency Level: 50
Time taken for tests: 200.007 seconds
Complete requests: 33106
Failed requests: 32951
(Connect: 0, Receive: 0, Length: 32951, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 1948268960 bytes
HTML transferred: 1938001392 bytes
Requests per second: 165.52 [#/sec] (mean)
Time per request: 302.071 [ms] (mean)
Time per request: 6.041 [ms] (mean, across all concurrent requests)
Transfer rate: 9512.69 [Kbytes/sec] received
Note the 32951 "failed" requests. I cannot figure this out.
As the test was running, I was able to access my web site from my home computer perfectly, albeit page load times at the bottom of the page were reported as .5 instead of the usual .02. However I never once had a failed request.
So why is AB reporting that half of the connections fail? And what does "Length: " mean in that context?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
没关系。 “长度失败”仅仅表明大约一半的时间响应的长度是不同的。
由于内容是动态的，因此它可能是会话标识符或类似的东西。
Nevermind. The "length failure" merely indicates that about half the time the length of the response was different.
Since the contents are dynamic, it's probably the session identifier or something like that.
换句话说，
apache 基准测试工具 (ab) 假设整个测试期间响应内容的长度是相同的。 它存储第一个响应的内容长度。 如果任何进一步的响应具有不同的内容长度，则会导致“长度失败”。
以下 apache 错误报告似乎证实了这一点： ASF Bug 42040
摘要：如果您正在提供任何可变长度的内容，您可能应该忽略这种 ab 请求失败。
编辑：我最近注意到
ab命令有一个新的（至少对我来说）选项：我可以在ab Version 2.3 <$Revision中看到它: 1528965 $> 但在 ab Version 2.3 <$Revision: 655654 $> 中看不到它，所以它可能是最近添加的。
To describe the issue in other words:
The apache benchmarking tool (ab) assumes that length of response content will be the same during entire test. It stores the content length of the first response. If any of further responses have different content length, they result in "length failures".
Following apache bug report seems to confirm that: ASF Bug 42040
Summary: If you are serving any content of variable length, you should probably ignore this kind of ab request failures.
Edit: I have recently noticed that the
abcommand has a new (at least for me) option:I can see it in ab Version 2.3 <$Revision: 1528965 $> but can't see it in ab Version 2.3 <$Revision: 655654 $>, so it was probably added relatively recently.
很抱歉重新提出一个老问题，但这是谷歌中出现的第一个问题。 有时 ab 报告的长度错误可能是由实际问题引起的：如果在客户端尚未收到 Content-Length 标头中声明的字节总数之前，服务器端关闭了连接。 如果客户端和服务器之间存在其他方，例如天真的手工负载均衡器（我的情况），则可能会发生这种情况。
Sorry to ressurrect an old question, but it was the first that popped up in Google. Sometimes the length error reported by ab may have been caused by a real problem: if the connection is closed server-side before the total amount of bytes declared in the Content-Length header has not been received by the client. That can happen if there are other parties between the client and the server, for example, naive handcrafted load balancers (my case).