-------------------------------------------------- From: "Jeff Trawick" <traw...@gmail.com> Sent: Tuesday, November 24, 2009 11:24 PM To: <dev@httpd.apache.org> Subject: Re: [mod_fcgid] Feedback / Suggestions
> On Tue, Nov 24, 2009 at 10:05 AM, Edgar Frank <ef-li...@email.de> 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 ;) > Pipeline is a little complex. FastCGI process would write during reading. so mod_fcgid should check both read and write on the socket, and read/write while the socket is readable/writeable. But is do-able :) Any one interesting? >> >> 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 > clients. > Yes, Jeff is right :) >> (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 > In this case, one httpd thread(process) will have to bind to one FastCGI process. I don't think connect() to a local pipe/unix domain socket is the bottle-neck, so let it be? >> 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. > connect() may be bottle-neck if using external FCGI backend. But now mod_fcgid don't support external FCGI backend yet.
