Long delay *after* PHP processing
"Felix E. Klee" <[email protected]> Sat, 5 Feb 2011 14:29:47 +0100
| Newsgroups | gmane.comp.web.fastcgi.devel |
|---|---|
| Message-ID | <[email protected]> |
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: http://delay.tmp.f76.eu/ 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 simple: <?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