0

On Bluehost shared hosting (Apache 2.2 + FastCGI + APC), I have the problem that some requests take almost exactly one minute to respond. Yet time spent in PHP is only two seconds. To demonstrate the issue, I created a temporary test page.

Sample output:
(source: inka.de)

When asking Bluehost support about the issue, I got the following reply: “the fastcgi process don't stay running they will only stay running for a certan period which would explain the timeouts you are seeing it traffic would spawn new ones. [...]”

I understand that spawning new FastCGI processes takes some time. But almost exactly one minute? That must be some timeout. But which timeout may that be?

What I want in the end: No request should take longer than five seconds to respond, even if it fails. When I asked Bluehost support to set the Apache TimeOut directive accordingly, they told me: “we do not modify the Apache Config File even on a virtual host level.”

Glorfindel
  • 1,213
  • 4
  • 15
  • 22
feklee
  • 505
  • 5
  • 19
  • The latest reply I got from Bluehost (keep in mind that the script is really simple): _“Its not the spawning a new fastcgi process that is the problem it is that once the fastcgi process times out it gives a SIGTERM and then ends and the delay looks to be from the script waiting for something that will never happen since the fastcgi process no longer exists. Here is the system calls for the last time it runs;_ – feklee Feb 05 '11 at 13:32
  • `05:12:03.612246 shutdown(3, 1 /* send */) = 0 05:12:03.612311 recvfrom(3, "\1\5\0\1\0\0\0\0", 8, 0, NULL, NULL) = 8 05:12:03.612366 recvfrom(3, "", 8, 0, NULL, NULL) = 0 05:12:03.612406 close(3) = 0 05:12:03.612464 accept(0, 0x7ffff9bb4cc0, [112]) = ? ERESTARTSYS (To be restarted) 05:12:11.388084 --- SIGTERM (Terminated) @ 0 (0) ---` – feklee Feb 05 '11 at 13:33
  • _Our fastcgi configuration is not always compatible with every script which is why regular php is provided. If your scripts are not working under fastcgi then you should just run them using regular php.”_ – feklee Feb 05 '11 at 15:10
  • Just got another reply from Bluehost: _“Our fastcgi setup works just fine with sleep, just not with the amount of sleep time you are using in your loop. If you want to run this then you unfortunately will not be able to use php5(fast-cgi).”_ Could that really be the explanation? I was able to reproduce the problem with a sleep time as low as one second. – feklee Feb 06 '11 at 10:07
  • It just might be true.. They could by recycling application pools, and your sleep is long enough that the pool is recycled in the middle of your request. – beans Feb 07 '11 at 01:09

1 Answers1

2

I pounded on your server quite a bit. Here's what I found:

  • I couldn't reproduce the problem with sleepTime=0.
  • With sleepTime=2, I got several 500 server errors -- as well as seeing the problem you describe.
  • When the problem occurs, the response Date header shows that only 2 seconds have elapsed -- so the request gets to the server in a timely fashion.
  • The problem happens w/ Connection: keep-alive, and with Connection: close, but an interesting point is that the server's Keep-Alive response header's "max" number occasionally jumps (as in from 25 to 18), and the server often closes the connection unexpectedly (before max runs out).

I would have put this in a comment, since it's not much of a solution -- but I ran out of room. You definitely have a problem that could cause your host to lose customers, so I think they should take you more seriously.

beans
  • 1,580
  • 13
  • 16
  • Thanks for pounding the server! And thanks for pointing me to the date header. In fact it looks as if the response is generated in time. But somehow sending it back takes about a minute. That's strange. Any idea what may be the reason? – feklee Feb 05 '11 at 09:13
  • Would like to vote for the reply, but: **Vote Up requires 15 reputation** – feklee Feb 06 '11 at 10:06