On 11/28/05, Nick Kew <[EMAIL PROTECTED]> wrote:
> On Sunday 27 November 2005 23:09, Olaf van der Spek wrote:
>
> > > Nope.  There's the old mod_fastcgi and the more up-to-date mod_fcgid
> > > out there.  Why does the world need another?
> >
> > But not in the official Apache distribution.
>
> How is that a problem?

It means the module is available on far less hosts. And with
non-dedicated hosts that's a significant issue (I think).

> > And not with a
> > Debian/DFSG-free license.
>
> Huh?  If debian has taken to rejecting the GPL, what do they have left?
> Not the Linux or Hurd kernels, for starters.

Oops, I assumed you referred to the one from http://fastcgi.com/

> > KeepAliveTimeout is 15 by default. I guess/think the majority of
> > processes is idle during most (> 50%) of the time. I'm not sure, but
> > don't these idle processes still consume a lot of memory and
> > (persistent database connection) resources?
>
> Yep.  Shifting that overhead to fastcgi doesn't get rid of it - unless

Why not?
Fastcgi isn't tied up during the keep alive idle time.

> (as I suggested) the PHP is a small proportion of total traffic, so the
> fastcgi can be a lot smaller than the main server.  But then, the same
> applies to proxying another Apache instance.
>
> > A separate process would also allow you to run PHP with other user IDs
> > and process priorities/privileges and provide fault isolation (apache
> > process/connection doesn't crash when PHP does).
>
> Sounds like fastcgi will suit you nicely.  I still don't see the problem.

No problem indeed if fastcgi is being used. I thought you were arguing
for just using the prefork mpm.

> (BTW, I sent the mod_fcgid maintainer a patch to build cleanly with
> Apache 2.1.8/9 a few weeks ago.  Hopefully he'll review and apply it).
>
> > > running PHP as CGI, under fastcgi, or on a separate server instance
> > > running with prefork and proxied by the primary server?
> >
> > PHP as CGI causes too much overhead I think.
>
> That would depend on the volume of PHP usage.

Of course.

Reply via email to