235

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?

BenMorel
  • 34,448
  • 50
  • 182
  • 322

3 Answers3

399

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.

Jeff Atwood
  • 63,320
  • 48
  • 150
  • 153
  • 8
    Hey, I just ran into the same "problem" and am glad this answer was here. Thanx! – Richard Hurt Jul 17 '09 at 09:49
  • 1
    Me too! Can't they call it something besides a "failure"!? – scotts Sep 04 '09 at 21:42
  • 2
    Thanks for the answer, I had exactly the same doubt. – Saiyine Jun 20 '10 at 00:59
  • 70
    Yes, two years later this answer is still really useful. – Sergi Mar 30 '11 at 11:59
  • Yes! This is why I love SO. Just learned about ab, and I did not find this information in the man page. – snapfractalpop Mar 16 '12 at 21:39
  • 11
    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 06:43
  • 2
    If you want to be certain they are all code 200, you can do something like `ab -n 100 -v 2 https://your-calendar.com/pages/home | egrep "Status|Failed" | sort | uniq`, which will print e.g. "Failed requests: 4" "Status: 200 OK" – Confusion May 13 '14 at 19:14
  • Note to Tal Lev-Ami: ab does show non 2xx responses. It doesn't specifically tell you what they are, but in the example above the fact there is no line saying "Non-2xx responses:" we can assume there were no 500 errors – Michael Bissell Nov 13 '14 at 00:44
  • 6
    Actually it's explained in the ab manual here http://httpd.apache.org/docs/current/programs/ab.html "If the document length changes during testing, the response is considered an error." – Захар Joe Feb 14 '15 at 11:17
  • 1
    6 years later, still very much useful – GreenScape Jun 17 '15 at 09:01
  • 1
    8 years later and still helpful. – DarthVader Jul 19 '17 at 10:50
  • can anyone please help me to understand about "Requests per second" include fail requests also? – Zaheer Nov 21 '19 at 06:10
  • 12 years later, this response still helpful. Thanks for that! – Bruno Paulino Aug 19 '21 at 13:39
158

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.

Dariusz Walczak
  • 4,848
  • 5
  • 36
  • 39
  • 4
    For anyone on a Mac, chances are your version of ab is behind and -l won't take. You can install from source or via homebrew, but "brew install ab" doesn't work because it's part of the apache package - you can install with "brew install homebrew/apache/ab". – netpoetica Jan 05 '15 at 19:31
10

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

zentrunix
  • 2,098
  • 12
  • 20