daniel at rimspace.net
Thu Sep 14 00:25:17 PDT 2006
Scott Penrose <scottp at dd.com.au> writes:
> On 14/09/2006, at 13:43, Daniel Pittman wrote:
>> Apache also supports FastCGI -- with the original FastCGI module and
>> the newer (and more free) FCGI module. Both of these give the same
>> benefits as lighttpd and FastCGI, plus the advantages that mod_perl
>> and other Apache modules provide.
> Nice thing about the above is that even though your code is FastCGI,
> as you mentioned you can still use mod_perl, which means we can still
> use the filters and auth etc.
Absolutely. I think out of process code is a good thing in general, but
it is not always appropriate. It increases latency and context
switching, both of which can be killers for filter applications, etc.
> This come very much down to if you are writing apache or an
> If you want to write Apache - e.g. something that uses Subrequest, has
> access to Apache internals, Authentication, Filtering etc - mod_perl
> is perfect.
Yeah, I agree, although I think we would disagree about where the line
is drawn: you seem to push more stuff into Apache than I think is worth
> An example of an application which should exist (probably) in mod_perl
> is things like a File Manager and Gallery - as it is self referring to
> internal data - e.g. other images or files.
In both cases I see these as generally bad candidates for in-process
* both perform long running, blocking operations on system resources
* both may generate large volumes of dynamic data
* both may need to be terminated in resource-exhaustion situations
Now, mod_perl works OK in the same situation, but it is nicer to
isolate those risky processes away, in my eyes. I can see how folks
could disagree with that assessment though. :)
Digital Infrastructure Solutions -- making IT simple, stable and secure
Phone: 0401 155 707 email: contact at digital-infrastructure.com.au
More information about the Melbourne-pm