I have a php application running on IIS 7.5 , php 5.4 running as fastcgi. The application works absolutley fine with the exception that long running php scripts seem to hang; no 500 error they simply seem never complete and return the results to the browser.
I've written a simple test script below to eliminate the possibility of programming error in the main app :
<?php echo "Testing time out in seconds\n"; for ($i = 0; $i < 175; $i++) { echo $i." -- "; if(sleep(1)!=0) { echo "sleep failed script terminating"; break; } } ?>
If I run the script beyond 175 seconds it hangs. Below that it will return the results to the browser.
Here are the time out parameters that I've set for php and fastcgi. I've also played around setting these really low in order to get various time out errors and have succeeded which brings me to the conclusion that there's another setting that I'm missing .. perhaps.
Correct me if my presumptions are wrong but would it be fair to say that if a script times out the browser will get an error where as if a script is killed off by IIS before completion then nothing is returned to the browser and you get a what looks like a hang as far as the browser is concerned?
First I woulf look at the IIS logs for what response was sent to the client. And then follow the request through with Failed Request Tracing. That should give you a better understanding of what is occuring.
OK, I stumbled across which app pool it's using through phpinfo and it seems it's the default application pool which has sufficiently high timeout and shouldn't be causing the issue.
2012-11-26 15:37:19 server ip GET /temp/script-timeout-test.php - 80 - my IP Mozilla/5.0+(Windows+NT+5.1;+rv:16.0)+Gecko/20100101+Firefox/16.0 200 0 121 201661
That's the request for the test script and it's returning a 200 which suggests all is OK but the browser behaves like it's hung.
What happens when you run the PHP test script from the command line?
Take a look at the HTTP API logfiles in c:\Windows\System32\LogFiles\HTTPERR. You'll find information about the reading these logs in
KB 820729. Also set up a Failed Request Tracing rule and inspect those logs (as Rovastar mentioned). It could be a timeout setting in which the server disconnects the connection with the client; TCP or a website related timeout setting (see Registry and
IIS Connection Time-out in website's AdvancedSettings). The HTTP API logfile will show this.
Although IIS sent a 200 http status - so it sent the correct information - there was an error with it getting to the client.
Win32status code is 121
If you look this up it i:
The semaphore timeout period has expired.
Which in reality is a network communication error. This is normally route or proxy problem.
I would packet sniff your network to see where this timeout occurs.
I think you will find that the response was sent all ok for from IIS (hence the 200) but the client never received it and the confirmation acknowledgement package was not returned correctly..
@Rovastar, been away from this thread for a while but I did look up the 121 error and came to the same error explanation as yourself. Exactly how what I did worked around the semaphore issue is beyond me.
I've now gotten to the bottom of the issue. Here's a cut and paste from my stackoverflow thread where I explain the issue and solution I came to. Hopefully this will give other people pointers to the various settings affecting long running scripts.
If a long running script doesn't communicate with the browser , after 180 seconds or so most browsers will become unresponsive to the server returning the results. The server script wasn't hanging or being terminated, it was the browsers (ie,ff and chrome)
becoming unresponsive.
To check this , I ran my script and watched the status of the request. IIS manager-> select the server-> select worker processes(central pane)->select the application pool-> select view requests (right hand pane) and watched the status and time elapsed columns.
You will have to repeatedly click "show all" to see the values updating.
The state changed from ExecuterequestHandler to Sending response and then the script finished as it should but the browsers still looked like they were waiting for the server to respond.
I updated my test script from the above to this to ensure the browsers were being fed responses regularly:
<?php
@ini_set("output_buffering", "Off");
@ini_set('implicit_flush', 1);
@ini_set('zlib.output_compression', 0);
@ini_set('max_execution_time', 800);
header( 'Content-type: text/html; charset=utf-8' );
echo "Testing time out in seconds\n";
for ($i = 0; $i < 600; $i++) {
echo $i." -- ";
if(sleep(1)!=0)
{
echo "sleep failed script terminating";
break;
}
flush();
ob_flush(); }
?>
The output was't coming back to the browsers bit by bit as it should and the problem remained.
Next step , I looked at response buffering on the server. The setting was set to a very high number and meant that flushing wouldn't work. So I set ResponseBufferLimit to 0 as per the instructions provided by @Dario in
PHP flush stopped flushing in IIS7.5 .
RichardS71
5 Posts
Long running php/fastcgi script hangs on IIS 7.5
Nov 23, 2012 04:44 PM|LINK
I have a php application running on IIS 7.5 , php 5.4 running as fastcgi. The application works absolutley fine with the exception that long running php scripts seem to hang; no 500 error they simply seem never complete and return the results to the browser.
I've written a simple test script below to eliminate the possibility of programming error in the main app :
<?php echo "Testing time out in seconds\n"; for ($i = 0; $i < 175; $i++) { echo $i." -- "; if(sleep(1)!=0) { echo "sleep failed script terminating"; break; } } ?>If I run the script beyond 175 seconds it hangs. Below that it will return the results to the browser.
Here are the time out parameters that I've set for php and fastcgi. I've also played around setting these really low in order to get various time out errors and have succeeded which brings me to the conclusion that there's another setting that I'm missing .. perhaps.
Correct me if my presumptions are wrong but would it be fair to say that if a script times out the browser will get an error where as if a script is killed off by IIS before completion then nothing is returned to the browser and you get a what looks like a hang as far as the browser is concerned?
fastcgi
Php
HostingASPNe...
734 Posts
Re: Long running php/fastcgi script hangs on IIS 7.5
Nov 23, 2012 06:39 PM|LINK
Hello,
You should increase the applicaion pool timeout.
Regards
Free ASP.NET Examples and source code.
RichardS71
5 Posts
Re: Long running php/fastcgi script hangs on IIS 7.5
Nov 26, 2012 01:08 PM|LINK
Thanks for your response HostingASPNet
I am a noob at this sort of server configuration, so I apologise in advanced for any silly questions.
I've looked at application pools and the server has 2. They both seem to pertain to .net only. I can't seem to find one that applies to fastcgi/php.
Any ideas?
Thanks
Rovastar
3321 Posts
MVP
Moderator
Re: Long running php/fastcgi script hangs on IIS 7.5
Nov 26, 2012 01:33 PM|LINK
First I woulf look at the IIS logs for what response was sent to the client. And then follow the request through with Failed Request Tracing. That should give you a better understanding of what is occuring.
RichardS71
5 Posts
Re: Long running php/fastcgi script hangs on IIS 7.5
Nov 26, 2012 02:39 PM|LINK
OK, I stumbled across which app pool it's using through phpinfo and it seems it's the default application pool which has sufficiently high timeout and shouldn't be causing the issue.
Any other ideas?
RichardS71
5 Posts
Re: Long running php/fastcgi script hangs on IIS 7.5
Nov 26, 2012 02:48 PM|LINK
Thanks for your response Rovastar.
I've looked at the iis logs and it shows
2012-11-26 15:37:19 server ip GET /temp/script-timeout-test.php - 80 - my IP Mozilla/5.0+(Windows+NT+5.1;+rv:16.0)+Gecko/20100101+Firefox/16.0 200 0 121 201661
That's the request for the test script and it's returning a 200 which suggests all is OK but the browser behaves like it's hung.
JanReilink
36 Posts
Re: Long running php/fastcgi script hangs on IIS 7.5
Nov 30, 2012 12:16 PM|LINK
What happens when you run the PHP test script from the command line?
Take a look at the HTTP API logfiles in c:\Windows\System32\LogFiles\HTTPERR. You'll find information about the reading these logs in KB 820729. Also set up a Failed Request Tracing rule and inspect those logs (as Rovastar mentioned). It could be a timeout setting in which the server disconnects the connection with the client; TCP or a website related timeout setting (see Registry and IIS Connection Time-out in website's Advanced Settings). The HTTP API logfile will show this.
Vevida Services - worry-free webhosting: http://vevida.com
Rovastar
3321 Posts
MVP
Moderator
Re: Long running php/fastcgi script hangs on IIS 7.5
Nov 30, 2012 01:00 PM|LINK
Although IIS sent a 200 http status - so it sent the correct information - there was an error with it getting to the client.
Win32status code is 121
If you look this up it i:
The semaphore timeout period has expired.
Which in reality is a network communication error. This is normally route or proxy problem.
I would packet sniff your network to see where this timeout occurs.
I think you will find that the response was sent all ok for from IIS (hence the 200) but the client never received it and the confirmation acknowledgement package was not returned correctly..
RichardS71
5 Posts
Re: Long running php/fastcgi script hangs on IIS 7.5
Dec 11, 2012 11:59 AM|LINK
@Rovastar, been away from this thread for a while but I did look up the 121 error and came to the same error explanation as yourself. Exactly how what I did worked around the semaphore issue is beyond me.
I've now gotten to the bottom of the issue. Here's a cut and paste from my stackoverflow thread where I explain the issue and solution I came to. Hopefully this will give other people pointers to the various settings affecting long running scripts.
If a long running script doesn't communicate with the browser , after 180 seconds or so most browsers will become unresponsive to the server returning the results. The server script wasn't hanging or being terminated, it was the browsers (ie,ff and chrome) becoming unresponsive.
To check this , I ran my script and watched the status of the request. IIS manager-> select the server-> select worker processes(central pane)->select the application pool-> select view requests (right hand pane) and watched the status and time elapsed columns. You will have to repeatedly click "show all" to see the values updating.
The state changed from ExecuterequestHandler to Sending response and then the script finished as it should but the browsers still looked like they were waiting for the server to respond.
I updated my test script from the above to this to ensure the browsers were being fed responses regularly:
<?php @ini_set("output_buffering", "Off"); @ini_set('implicit_flush', 1); @ini_set('zlib.output_compression', 0); @ini_set('max_execution_time', 800); header( 'Content-type: text/html; charset=utf-8' ); echo "Testing time out in seconds\n"; for ($i = 0; $i < 600; $i++) { echo $i." -- "; if(sleep(1)!=0) { echo "sleep failed script terminating"; break; } flush(); ob_flush(); } ?> The output was't coming back to the browsers bit by bit as it should and the problem remained.Next step , I looked at response buffering on the server. The setting was set to a very high number and meant that flushing wouldn't work. So I set ResponseBufferLimit to 0 as per the instructions provided by @Dario in PHP flush stopped flushing in IIS7.5 .
This solved the problem. Hope this helps someone.