[FASTCGI] Long delay *after* PHP processing

Felix E. Klee felix.klee at inka.de
Sat Feb 5 08:29:47 EST 2011

This is a question by a FastCGI user, not by a developer. Sorry for
that, but I couldn't find a more suitable mailing list.

Anyway, the problem is best seen by leaving the following page open for
some time:


Eventually, one of the requests will take almost exactly a minute to
respond. Yet the PHP script that is executed with FastCGI [1] is dead

  <?php sleep(2)

When you look at the Date response header, you will notice that the
delay of one minute is caused *after* execution of the PHP script.

Isn't that strange? What may be the reason?

By the way, the provider is Bluehost.com, and their last reply was:

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

Sorry, but if the above PHP script is not compatible with Bluehost's
FastCGI configuration, then what script is?

[1] Running on Apache 2.2. APC and Xdebug are completely disabled

More information about the FastCGI-developers mailing list