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 14:47:39 GMT
On Friday 02 October 2009 8:14:14 am Jeff Trawick wrote:
> On Fri, Oct 2, 2009 at 9:01 AM, Ricardo Cantu <ricardo@smartcsc.com> wrote:
> > 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:
> > > > 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.
> 
> My understanding is that mod_fastcgi's FastCgiExternalServer is for
> processes that mod_fastcgi doesn't manage at all.  It will route requests
>  to them but it can't start or stop them.  I think that matches the only
>  support in httpd trunk's mod_proxy_fcgi.
Your right it doesn't start or stop the process but does manage request 
handling. mod_fastcgi's FastCgiExternalServer accepts the following options:
-appConnTimeout and -idle-timeout. Rather than terminating the process on 
FCGIDIPCCommTimeout and FCGIDBusyTimeout we would abort the request and log 
it.

> 
> mod_fastcgi's FastCgiServer directive is similar in some respects to the
>  one I propose in this thread, but it has a key difference: It implies that
>  at least one instance/process will be maintained at all times,
>  irrespective of load.
This can already be done with FCGIDDefaultMinClassProcessCount.

> 
> The primary motivation for my new directive is to specify options that
> sometimes need to be associated with the application itself and not with
>  the context of a particular request that the application can handle.
This is perfect.

> Regardless, an option like InitialProcesses could be specified to pre-spawn
> processes.
> 
> Another approach, instead of specifying something like InitialProcesses
>  with the other options, is to call this options directive
>  "FCGIDCommandOptions", and have another directive that specifies that the
>  command is in fact a "static application" (to borrow the terminology from
>  mod_fastcgi).  Whether an application is started on demand or maintained
>  perpetually ("static application"), any options specified on
>  FCGIDCommandOptions would override settings from the vhost or defaults.
> 

I like the FCGIDCommandOptions idea. There are really two concepts here that 
need to be addressed.

One:
Would you like your process pre-spawned (and how many) then controlled by the 
pm based on load and various other directives?

Two;
Would you like your process pre-spawned and left alone? (Expect for requests 
that need to be aborted due to hanging up the server)







Mime
View raw message