httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricardo Cantu <rica...@smartcsc.com>
Subject Re: [mod_fcgid proposal] defining processing options for particular commands
Date Fri, 02 Oct 2009 13:01:49 GMT
On Friday 02 October 2009 5:35:03 am Jeff Trawick wrote:
> On Fri, Oct 2, 2009 at 5:15 AM, Barry Scott <barry.scott@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.)
Or command name ;)

> >>
> >>  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?

Yes, the changes you propose definitely fixes what seems to me currently a very 
odd setup.

> 
> > 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?
> 

From what I understand the point behind FastCgiExternalServer ("process to be 
started before any request arrive?") is to prevent the process manager from 
managing that process. Only FCGIDIPCCommTimeout and FCGIDBusyTimeout would 
apply to "InitialProcesses n". Correct me if I'm wrong, don't think it had to 
do with aggressiveness or delay of spawning. 


Mime
View raw message