httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: [mod_fcgid] Feedback / Suggestions
Date Tue, 24 Nov 2009 15:24:58 GMT
On Tue, Nov 24, 2009 at 10:05 AM, Edgar Frank <> wrote:
> Hi dev,
> I'd like to suggest to following changes / offer feedback for mod_fcgid:

my 2cents below

> (1)
> mod_fcgid should be capable of specifying an external FCGI server.
> (2)
> In conjunction with (1), mod_fcgid should be able to select the backend
> server based on request data.

I'd much rather see effort put into mod_proxy_fcgi to support this use
case.  I wish somebody, perhaps myself, had time to work on it.  It
doesn't seem that hard a task.

In the interim, is mod_fastcgi really that bad?

> (3)
> mod_fcgid currently buffers the complete input from the client
> (occasionaly in a temp-file if the request is large) before it passes it
> through to a FCGI backend. Could this be made configurable in a way like
> File|Memory|Pipeline? (file - as is | memory - buffer in memory always
> | pipeline - directly pass the read data to the backend)

This will definitely be resolved ;)

> Or otherwise, can someone explain the details to me why it is as it is?
> Especially in terms of not pipeling data directly (maybe after a little
> buffering to build proper FCGI packets)? The comment in
> fcgid_bridge.c:452 (add_request_body) left me clueless. Why would this
> keep the server in processing too long? Processing takes its time either
> way, I'd assume. Looking forward to enlightment. :)

I can only guess that the problem at hand when this was implemented
was that some backend application processes were so expensive that
that they couldn't be tied up until all data had been read from slow

> (4)
> Would it make sense to use the FCGI feature to multiplex several
> requests over a single connection? Does any backend support this
> feature anyway?

no idea here

> When thinking of an external FCGI backend with a socket connection and
> very high Requests/s, this could keep open connections and
> used/available ports much lower.

View raw message