Some background information on FastCGI and how these settings work. Apologies if this review for most:
The original CGI mechanism works by creating a new process when an HTTP request comes in, sending just one request to that process, and then allowing the process to exit. This mechanism can work well on a system where process creation is light weight (ie. Unix based OSs.) On Windows, though, process creation is a very heavy weight operation, thus CGI tends to be very slow on any Windows based web server, IIS included.
FastCGI is very similar to CGI in many ways. One of the key differences is that it can allow the handling process to remain alive after serving a request and then accept further requests. Our FastCGI handler (and most others, too) also supports spinning up multiple CGI processes and keeping them all alive. This is how FastCGI gains its performance advantage over the built-in CGI handler for IIS.
That said, here are the meanings for each of the config lines:
QueueLength: This is the number of requests that the FastCGI handler will hold in queue while waiting for an available FastCGI process. This queue needs to exists because each FastCGI instance can only handle one concurrent request.
MaxInstances: This is the number of processes that the FastCGI handler will start for each process path. This corresponds directly to how many concurrent requests can be actually doing work (and any requests beyond this will be queued as above.) Note that we will only start new processes when they are needed. For example, if you use the value of 4 as above, we will not start 4 processes unless we actually have that many concurrent requests. If, for example, there was never more than one concurrent request, we would only start one process and never reach the maximum.
InstanceTimeout: This is the timeout for the communication between the actual CGI processes and the FastCGI handler. When it expires, the associated process is terminated.
InstanceMaxRequests: This is the number of requests that the FastCGI handler will send to a given process before shutting it down and starting another. So in the above example, the FastCGI handler will send 200 requests to a process until recycling it.
Note that there is another setting which does not exist in the default fcgiext.ini file:
FlushNamedPipe: This property can be added to the fcgiext.ini file for a specific process to control the behavior that occurs when a process terminates unexpectedly. The possible values are 0 or 1. If the value is set to 1, the FastCGI handler will attempt to flush any outstanding I/O on the named pipe connection between FastCGI and the process when the process terminates. Note that the FastCGI handler may hang waiting for the flush to occur, depending on the properties of the actual FastCGI process. The default value is 0, which conforms to the php-cgi.exe behavior.
I hope that this helps. If you have further questions, please feel free to ask.
Thanks,
-Wade