问题
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?
Thanks
回答1:
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.
回答2:
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 ab command has a new (at least for me) option:
-l Accept variable document length (use this for dynamic pages)
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.
回答3:
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).
来源：https://stackoverflow.com/questions/579450/load-testing-with-ab-fake-failed-requests-length