[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
Eventually, one of the requests will take almost exactly a minute to
respond. Yet the PHP script that is executed with FastCGI  is dead
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, ) = ? 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?
 Running on Apache 2.2. APC and Xdebug are completely disabled
More information about the FastCGI-developers