Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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:

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

share|improve this question
    
I now simplified the script even further to just <?php sleep(2);. And I disabled APC and Xdebug entirely. –  feklee Feb 5 '11 at 13:06
    
OT: Seems like something is wrong with Markdown in comments at the moment. Also there was an issue earlier where I wasn't allowed to edit a comment that I added less than a minute before. –  feklee Feb 5 '11 at 13:11
    
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 5 '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 5 '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 5 '11 at 15:10

1 Answer 1

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.

share|improve this answer
    
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 5 '11 at 9:13
    
Would like to vote for the reply, but: Vote Up requires 15 reputation –  feklee Feb 6 '11 at 10:06

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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