I have a simple PHP script running on an Apache 2.2 (almost default configuration). When running the command ab -n 1 <address> where address is either the local IP or the domain name, I'm receiving about a 15-second window of the socket staying open, after receiving all the data in the first second or so.

When hitting the same page with a browser, I'm getting sub-100ms responses. I understand that most modern browsers are supporting the Keep-Alive header and storing persistent connections with some sort of TTL timer. So when I ran the ab -kn <whatever> command, I started getting results closer to what I expected from the performance through the browser.

Is this normal behavior? Is there something incorrect with my server configuration?


I've ran ab again with the -v 2 flag, this was the output:

Benchmarking localhost (be patient)...INFO: POST header == 

Host: localhost
User-Agent: ApacheBench/2.3
Accept: */*

LOG: header received:
HTTP/1.1 200 OK
Date: Sat, 02 Apr 2011 05:09:42 GMT
Server: Apache/2.2.16 (Ubuntu)
Vary: Accept-Encoding
Content-Length: 86
Content-Type: text/html

<html><head><title>Dynamic</title><body><h1>This is another action!</h1></body></html>

Server Software:        Apache/2.2.16
Server Hostname:        localhost
Server Port:            80

Document Path:          <PATH>
Document Length:        86 bytes

Concurrency Level:      1
Time taken for tests:   15.076 seconds
Complete requests:      1
Failed requests:        0
Write errors:           0
Total transferred:      242 bytes
    HTML transferred:       86 bytes
Requests per second:    0.07 [#/sec] (mean)
Time per request:       15075.916 [ms] (mean)
Time per request:       15075.916 [ms] (mean, across all concurrent requests)
Transfer rate:          0.02 [Kbytes/sec] received

However, the browsers are also accepting a Content-Encoding: gzip and a content-length of 97 from php's zlib compression - and possibly an Apache 2.2 deflate feature. The 15-second pause happens after the entire body is sent, before ..done.


I think you're asking, "Is it normal for ab -n 1 to wait for the connection tear-down (15 seconds) before returning, even though the server sends all your data immediately?"

That's not normal.

Run with verbosity = 2 (ab -v 2 <url>), and check the headers that are returned. Is the server sending Connection: close? Is it sending an incorrect Content-Length?


I now see your body is a single line, so perhaps ab isn't happy about not getting CR LF after the entity body. I can't reproduce that sort of output with apache and a text file -- apache adds CR LF after the body, and ab returns immediately. How are you producing this output?

| improve this answer | |
  • I've edited my original answer with more details from your suggestion. – efritz Apr 2 '11 at 5:16
  • With or without newlines after the content body it displays the same behavior. – efritz Apr 5 '11 at 6:42
  • Mysterious. The next thing I would do would be to try to figure out what ab is waiting for. You can run ab inside strace, and figure if it's waiting for a particular bit of data to return. Or, if you want to know if this is just an ab-ism, you can see if a request with netcat produces the same behavior ( echo "<paste ab's request here>" | nc localhost 80 ).. – beans Apr 5 '11 at 13:33
  • Seems like it's just a quirk with ab, then. nc doesn't wait and displays the correct response. – efritz Apr 5 '11 at 22:49

Worked for me after I added these headers to the server's response

Connection: Keep-Alive Content-Length: xxx

Strangely, if I do not add the 'Connection' header, ab times-out in '-k' mode. Looks like some bug in the implementation.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.