0

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?

[EDIT]

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

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

---
GET <PATH> HTTP/1.0
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>
..done


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.

efritz
  • 103
  • 1
  • 5

2 Answers2

1

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?

[EDIT]

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?

beans
  • 1,550
  • 13
  • 16
  • I've edited my original answer with more details from your suggestion. – efritz Apr 02 '11 at 05:16
  • With or without newlines after the content body it displays the same behavior. – efritz Apr 05 '11 at 06: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 "" | nc localhost 80 ).. – beans Apr 05 '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 05 '11 at 22:49
0

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.

Ashish Tyagi
  • 1