Request TimeoutRSS

1 reply

Last post Mar 14, 2011 11:35 AM by David Di - MSFT

  • Request Timeout

    Mar 04, 2011 08:58 PM|Streamworks|LINK

    Hi Folks,


    Got a question about the Request Timeout setting for FastCGI.  To my understanding if Joe Smith comes to our web site which is a PHP driven site and there no php-cgi.exe process currently running it will start one in order to build the page.   Now if Joe Smith leaves 2 minutes later and let's say we have the Request Timeout set to 4 minutes... then 2 minutes after Joe Smith leaves the php-cgi.exe process will die.  But what I am wondering is let's say Mike Jones comes to the site 1 minute after Joe left.... the process is still alive so that process would be used to build MIke's page.


    But what I am wondering, is if Mike stays at the site for 2 minutes (or more) would the first process that was started by Joe then used by Mike still terminate after it's four minutes?


    In our application we are thinking of going back to PHP to send files - but some of these files are huge so we need a long Request Timeout (plus more Max Instances than the default 4 in case there are more than 4 downloading at a time).  So going back to Joe and Mike, if Joe comes and downloads his file and his PHP-CGI process is still alive when Mike comes to download his file (after Joe), what would happen if the Request Timeout from the process Joe started happened a few minutes after Mike started his download?  Would his download terminate - then would have to start all over again (thus starting a new PHP-CGI process)?


     Or would the process realize it is not idle and even though it is past the Request Timeout, stays running?




  • Re: Request Timeout

    Mar 14, 2011 11:35 AM|David Di - MSFT|LINK


    I think you may be mixing a few different settings together.  The settings of interest here are going to be the following:

    • Activity Timeout - Specifies the time, in seconds, that a FastCGI process for this application is allowed to run without communicating with IIS.
    • Idle Timeout - Specifies the time, in seconds, that a FastCGI process for this application is allowed to remain idle.
    • Request Timeout - Specifies the maximum allowed time, in seconds, for request processing.

    The Request Timeout is specific to each individual request and the timer runs only for that request and is independent of the other timers.  If Joe's (or Mike's) request takes longer than this time period the request is terminated and an error is generated.

    The Idle Timeout is how long we will maintain a given CGI executable without receiving requests.  If Joe makes a request that starts a CGI executable it will sit waiting for additional work for this long after his request completes before the process exits.  If Mike's request comes in within this time period after Joe's request completes it should be handled by the same instance of the CGI executable.

    The Activity Timeout is how long we will let the request process without receiving some sort of notification back from the CGI process indicating it is still working - this part is dependent on the actual CGI executable itself and is used as a watchdog to make sure we have some means to detect a hang if we have a long Request Timeout.  I believe that the default value for this should be fine for most PHP work.

    There is no setting that I can find for anything like 'Maximum Lifetime' that sets a maximum duration for the lifetime fo a given CGI executable instance.  There is a setting for instanceMaxRequests that specifies the maximum number of requests that a single executable instance is allowed to process but that is a function of the number of requests rather then the duration.

    Overall, if the executable is still alive when the second request comes in the request should be routed to it and it will not arbitrarily shut down in the middle of processing a request.  My only suggestion would be to make sure your Request Timeout value is large enough to cover the entire duration of the request plus a margin to account for any unexpected delays in processing.


    Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.


    David Dietz
    Microsoft Online Community Support