Why no minServers? RRS feed

  • Question

  • User244989351 posted

    I have a FastCGI application that has a long startup time.  If I start it on demand, the first request will take like 30 seconds, and using the IIS+ existing cgi-fcgi or isapi fastcgi often returns some type of error instead of just a delayed response.

    Why not (like mod_fastcgi) prelaunch the processes when the server starts to address this scenario?

    Likewise,  can you make the idle process reaping configurable?



    Wednesday, November 1, 2006 1:25 PM

All replies

  • User209782248 posted

    You can edit the configuration for your fastCGI application pool, to configure a number of settings including the timeout for a FastCGI request, and the number of processes.

    Check out Rick's post about the configuration options available today - http://blogs.iis.net/rickjames/.  You can set these directly in applicationHost.config, or by using AppCmd to edit the collection entry for your FastCGI application:

    > %SystemDrive%\windows\system32\inetsrv\appcmd.exe set config -section:fastCGI /?


    Wednesday, November 1, 2006 2:35 PM
  • User244989351 posted

    Thanks Mike for replying. 

    It was from Rick's post that I determined that the handler is launching processes "on demand" and automatically terminating idle processes.

    Quote: "Processes are spawned on demand up to the maximum (there is no MinServers setting)"

    This is not ideal for apps that have a long startup time (compiling, opening connections, precaching results etc).  Think about ASP.NET 2.0 and precompilation -- it solves a somewhat similar problem of not taking the compilation hit on first request.    If you needed it in ASP.NET don't you think you'll need it for FastCGI?

    Also I imagine upping the timeout for the FastCGI request might allow me to return a very slow response on first hit instead of an error,  but can you understand that this is not ideal?

    Don't kill MinServers,  or at least help me understand why it's a bad/challenging/version2 thing. 


    Wednesday, November 1, 2006 3:01 PM
  • User209782248 posted


    Precompilation in ASP.NET is an external, ASP.NET specific concept.  If something like that existed for PHP, or RoR, they can take advantage of it the same way to alleviate the need to to do initialization type tasks on the first request.  But, unless I am wrong, there is no such thing for PHP especially that it is interpreted.

    What you are talking about is making a fake request to some urls in your app before the worker process starts accepting requests, so that it could do some of these expensive things before the site goes live, regardless of what the app framework is.  This is a general helpful feature that we are planning for IIS7 server, which would then be used for any app regardless of host (fastcgi) or app framework (asp.net / php / java servlets / ruby / etc).

    The minServers thing helps a little bit by proactively starting a FastCGI process, but it doesnt actually help much in terms of your 30 second app initialization time because it doesnt make any requests to the PHP app.  You should be able to use the request prewarming feature once its ready to get the app really hot before the traffic hits.

    As far as how to deal with your first request issue - you are 100% on target - raise the timeout.  Let us know if you have other issues.



    Wednesday, November 1, 2006 8:24 PM
  • User244989351 posted

    Here's an stub fastcgi program in perl:

    use CGI::Fast qw(:standard);
    ### TIME_INTENSIVE_INITIALIZATION: Spend ~ 30 seconds here:
    ### use BigCode Library; open_db_connection(); cache_some_pages_in_memory();

    $COUNTER = 0;
    EVENT_LOOP: while (new CGI::Fast) {
    print header;
    print start_html("Fast CGI Rocks");
    h1("Fast CGI Rocks"),
    "Invocation number ",b($COUNTER++),
    " PID ",b($$),".",
    print end_html;

    You'll see from the code above (which is a pretty fcgi standard template across scripting languages - I've done tcl,php and perl) that the app initialization happens _before_ the requests are served. So minservers/prespawning would help because the init time would not be exposed to the user.  Believe me I know - this is not a theoretical issue I'm raising.

    If fake requests can be scheduled to happen every n minutes or so (like in aolserver/apache/coldfusion), then you could use that to ping your fastcgi process and prevent process culling,  effectively giving you minservers. I've had to do that before -- it's works but it's not as elegant as one line in a config file. 

    Also it leaves IIS 6 and 5 users (who won't have fake requests?)  out of luck, if that's the only solution. 

    Maybe they too will have workarounds,  but you can see how that complicates the documentation life of software projects hoping to target IIS?

    [aside: PHP has precompilation tools like Zend etc. but I don't know if any do ahead-of-first-request compilation.]


    Thursday, November 2, 2006 9:37 AM
  • User209782248 posted


    I see what you are saying.  We will have to see whether a minServers type approach makes sense for the next release of FastCGI.

    The request-prewaming is a much more useful features for IIS customers across the board though, which is why we are looking into it for IIS7.  Unfortunately, I am not aware of any support that would enable us to do it for IIS 5 / 6, unless you are doing it by making a real request to the machine from a prewarming script.


    Thursday, November 2, 2006 7:36 PM
  • User244989351 posted

    Thanks for you time replying to this Mike.

    Just wanted to note that request-prewarming combined with a configurable process reap time ( ie infinity) would also solve the issue for IIS7.

    By way of background, we have an originally mod_perl product with clients that have demanded IIS.  So we ported to FastCGI  and tried Shane C's fastcgi ISAPI implementation.  It was a little quirky, difficult to debug (for the timeout issue), and it didn't prespawn, so after some research we actually deploy Apache2/mod_fastcgi just to use it as a process manager.  It runs as a service and ensures that n perl fastcgi listener processes are always kicked off and waiting.  We now use cgi-fcgi.exe as a bridge between IIS and the Apache-managed processes because it's dead simple, works out of process so it doesn't effect IIS stability, and can be debugged from the command line.  Performance hit yes, but it's not been an issue for us.

    It's quite inelegant, but on the other hand it's been bullet-proof for a few years now.  I would love to ditch apache and go with pure IIS at some point if you can match features with your ISAPI module but the minserver/prespawn-equivalent is a showstopper. 

     Thanks for listening,





    Friday, November 3, 2006 11:52 AM
  • User-2026410440 posted

    John, this is a pretty interesting solution.  thanks for sharing!


    Friday, November 3, 2006 12:10 PM