httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Barry Scott <>
Subject Re: [mod_fcgid proposal] defining processing options for particular commands
Date Mon, 05 Oct 2009 09:07:44 GMT
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 <
>>> <>> 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
>>> 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.


View raw message