Ricardo Cantu wrote:
On Friday 02 October 2009 11:10:25 am Barry Scott wrote:
Jeff Trawick wrote:
On Fri, Oct 2, 2009 at 5:15 AM, Barry Scott <barry.sc...@onelan.co.uk
<mailto:barry.sc...@onelan.co.uk>> wrote:

    Jeff Trawick wrote:

        (instead of based on uri or vhost)

        FCGIDCommand /path/to/command
         IdleTimeout n
         MaxProcessLifetime n
         MinProcesses n
         MaxProcesses n
         MaxRequestsPerProcess n
         InitialEnv var[=val] ...
         <class>

        (the names of these options follow my proposal for the names
        of existing directives ;) )

        When a command is to be started by mod_fcgid, any options
        specified for the command on this directive override those
        defined for the uri, vhost, global, or the defaults.  When a
        wrapper is used, it is that wrapper which must be specified on
        this directive.  This directive is not required unless one or
        more options must be customized for a command.

        Initially this would be allowed only in global sections.
        InitialEnv can be repeated.

        Regarding *class*:  Something is needed to disable or alter
        existing management of applications based on their class.
         Currently a class is limited to the processes started by the
        same command within the same vhost (except when ServerName
        isn't specified) with the same identity.

        One possibility is to provide an option to ignore the vhost
        name when managing the class (IgnoreVHost or ClassIsGlobal).
         Another possibility is to set the name of the class to be
        used in lieu of the virtual host (ClassName foo), which could
        be used to the same effect but might be more useful in the
        future when the process manager can see per-server configs
        (for existing directives as well as FCGIDCommand).

        None of this would affect the identity checks.  (Processes
        with different uid/gid would never be considered to be in the
        same class.)

    This seems to offer all the features of mod_fastcgi process
    configuration and then go usefully beyond what mod_fastcgi does.


Thanks for looking.  Does anyone else care to comment?



    Is it possible to also ask for the fcgi process to be started
    before any request arrive?


Sure.  I guess there could be some "InitialProcesses n" option on this
directive.  (If this appears to be forgotten, open a bug at
https://issues.apache.org/bugzilla/ and set the severity to
"enhancement."  Product = Apache httpd-2, component = mod_fcgid.)

BTW, do you need to pre-spawn just on general principle (don't want
any initial delay), or is the on-demand spawning not aggressive
enough, such that it takes too long to create an adequate number of
application processes?
We have a setup that can be CPU time and memory limited.
Using Static servers allows the start up overhead to be suffer once at
boot time.
Our fast CGI servers are python processes that run very fast but can be
slow to start,
a few seconds, which is bad for response times.
So do you want a fixed number of these python processes to be pre-spawned and for the pm to stay out of the way? (never start any more or terminate any that were pre-spawned)
Fixed number pre-spawned, never terminated. If any die then restart them.

Barry

Reply via email to