Take the 2-minute tour ×

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?


share|improve this question
Does your website have a load balancer? See my blog post on load testing with load balancers that might explain the "it works for me" situation in load testing. –  Patrick Lightbody Feb 24 '09 at 19:57
add comment

4 Answers

up vote 166 down vote accepted

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.

share|improve this answer
Hey, I just ran into the same "problem" and am glad this answer was here. Thanx! –  Richard Hurt Jul 17 '09 at 9:49
Me too! Can't they call it something besides a "failure"!? –  scotts Sep 4 '09 at 21:42
Thanks for the answer, I had exactly the same doubt. –  Saiyine Jun 20 '10 at 0:59
Yes, two years later this answer is still really useful. –  Sergi Mar 30 '11 at 11:59
Don't be too quick to attribute this to variable content length mismatches. ab doesn't report HTTP status code 500 as errors in its summary. The reason for the length mismatch might be that you have a real error. You can use -v 4 to get more info (better pipe to a file as there will be a lot of printout). –  Tal Lev-Ami May 22 '13 at 6:43
show 2 more comments

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.

share|improve this answer
add comment

but we do see that the requests which it shows as failed are actually logged in nginx errors log. So it is really length mismatch? also the content being served is always the same from our end.

share|improve this answer
add comment

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).

share|improve this answer
add comment

Your Answer

