Re: [mod_fcgid] Feedback / Suggestions
Eric Covener wrote: On 12/4/09, Barry Scott wrote: Eric Covener wrote: On Thu, Dec 3, 2009 at 5:57 AM, Barry Scott wrote: Jeff Trawick wrote: On Tue, Nov 24, 2009 at 10:05 AM, Edgar Frank wrote: In the interim, is mod_fastcgi really that bad? mod_fastcgi is fine for handling GET/POST requests, but it fails to implement Authorization or Authenication. So yes mod_fastcgi is really bad. mod_fastcgi has supported this for many years: http://www.fastcgi.com/drupal/node/25#FastCgiAuthorizer http://www.fastcgi.com/drupal/node/25#FastCgiAuthenticator It does not work or I'd have used it. And I tried to make it work. There is a lot of missing code, compare to mod_fcgid implementation of the same. Simple tests work for me. Hmm, Then I must have got something wrong when I tried to get this working, or you have patches I don't. When I looked at the sources and compared to mod_fcgid it looked like there was code missing. It's too long ago now for me to recall the details to discuss. Barry
Re: [mod_fcgid] Feedback / Suggestions
On 12/4/09, Barry Scott wrote: > Eric Covener wrote: > > > On Thu, Dec 3, 2009 at 5:57 AM, Barry Scott > wrote: > > > > > > > Jeff Trawick wrote: > > > > > > > > > > On Tue, Nov 24, 2009 at 10:05 AM, Edgar Frank > wrote: > > > > > > > > In the interim, is mod_fastcgi really that bad? > > > > > > > > > > > > > > > mod_fastcgi is fine for handling GET/POST requests, but it fails to > > > implement > > > Authorization or Authenication. > > > > > > So yes mod_fastcgi is really bad. > > > > > > > > > > mod_fastcgi has supported this for many years: > > > > http://www.fastcgi.com/drupal/node/25#FastCgiAuthorizer > > > http://www.fastcgi.com/drupal/node/25#FastCgiAuthenticator > > > > > > > It does not work or I'd have used it. And I tried to make it work. > There is a lot of missing code, compare to mod_fcgid implementation > of the same. Simple tests work for me. -- Eric Covener cove...@gmail.com
Re: [mod_fcgid] Feedback / Suggestions
Eric Covener wrote: On Thu, Dec 3, 2009 at 5:57 AM, Barry Scott wrote: Jeff Trawick wrote: On Tue, Nov 24, 2009 at 10:05 AM, Edgar Frank wrote: In the interim, is mod_fastcgi really that bad? mod_fastcgi is fine for handling GET/POST requests, but it fails to implement Authorization or Authenication. So yes mod_fastcgi is really bad. mod_fastcgi has supported this for many years: http://www.fastcgi.com/drupal/node/25#FastCgiAuthorizer http://www.fastcgi.com/drupal/node/25#FastCgiAuthenticator It does not work or I'd have used it. And I tried to make it work. There is a lot of missing code, compare to mod_fcgid implementation of the same. Barry
Re: [mod_fcgid] Feedback / Suggestions
On Thu, Dec 3, 2009 at 5:57 AM, Barry Scott wrote: > Jeff Trawick wrote: >> >> On Tue, Nov 24, 2009 at 10:05 AM, Edgar Frank wrote: >> >> In the interim, is mod_fastcgi really that bad? >> > > mod_fastcgi is fine for handling GET/POST requests, but it fails to > implement > Authorization or Authenication. > > So yes mod_fastcgi is really bad. mod_fastcgi has supported this for many years: http://www.fastcgi.com/drupal/node/25#FastCgiAuthorizer http://www.fastcgi.com/drupal/node/25#FastCgiAuthenticator -- Eric Covener cove...@gmail.com
Re: [mod_fcgid] Feedback / Suggestions
Jeff Trawick wrote: On Tue, Nov 24, 2009 at 10:05 AM, Edgar Frank wrote: In the interim, is mod_fastcgi really that bad? mod_fastcgi is fine for handling GET/POST requests, but it fails to implement Authorization or Authenication. So yes mod_fastcgi is really bad. mod_fcgid is a very welcome as a supported httpd module. Barry
Re: [mod_fcgid] Feedback / Suggestions
On Thu, Nov 26, 2009 at 9:26 AM, Edgar Frank wrote: >> 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. > > Just an idea, I though about - what would you think about pulling > mod_proxy_fcgi up to the FCGI-code base of mod_fcgid? Could be kind of > difficult, as mod_fcgid is maintained separately at the moment, but IMHO > mod_fcgid has a much more sophisticated code in FCGI-communication (e.g. using > own bucket types) and adhering to the CGI standard. > > If, in theory, both were sitting on the same code base, any fixes/changes/ > enhancements in FCGI handling would affect and improve mod_proxy_fcgi, too. > This way, mod_proxy_fcgi would be the superior choice for externally spawned > workers (where dynamic worker selection really starts to make any sense) while > mod_fcgid cares about local workers and process management - and every module > would serve its very own purpose. > > Okay, this has some downsides, too, like increased testing overhead, but in > general I like the idea. > > I would be glad to hear your thoughts. In an ideal situation you don't have two separate modules. So don't go that way. ;) Spawning is nice but IMO not that important and in an ideal case you might want to run the backend with a different user ID than the frontend. Olaf
Re: [mod_fcgid] Feedback / Suggestions
On Tue, Nov 24, 2009, Jeff Trawick wrote: > On Tue, Nov 24, 2009 , Edgar Frank wrote: > > (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. Just an idea, I though about - what would you think about pulling mod_proxy_fcgi up to the FCGI-code base of mod_fcgid? Could be kind of difficult, as mod_fcgid is maintained separately at the moment, but IMHO mod_fcgid has a much more sophisticated code in FCGI-communication (e.g. using own bucket types) and adhering to the CGI standard. If, in theory, both were sitting on the same code base, any fixes/changes/ enhancements in FCGI handling would affect and improve mod_proxy_fcgi, too. This way, mod_proxy_fcgi would be the superior choice for externally spawned workers (where dynamic worker selection really starts to make any sense) while mod_fcgid cares about local workers and process management - and every module would serve its very own purpose. Okay, this has some downsides, too, like increased testing overhead, but in general I like the idea. I would be glad to hear your thoughts. Regards, Edgar
Re: [mod_fcgid] Feedback / Suggestions
On Wed, Nov 25, 2009 at 12:54 PM, Edgar Frank wrote: > 2009/11/25 Olaf van der Spek >> > Yes, you're right. In a FCGI_GET_VALUES request, the backend can send >> > arbitrary name-value-pairs. Unfortunately there is no standard way to tell >> > the frontend that this feature is supported. Maybe, making the name (and >> > expected value) of this name-value-pair configurable in mod_fcgid could >> > be a reasonable way. >> >> Doesn't sound reasonable either. If you introduce such a feature, it >> should simply be coordinated with other FastCGI stakeholders. > > You're right, again. I'm just wondering if such a change is likely to happen. > Last update was 2002. I'd like to propose a change to the FastCGI > stakeholders, if this makes any sense from a single, unrelated person. The official spec is unlikely to change, so you'd have to coordinate with other web server and backend developers. Olaf
Re: [mod_fcgid] Feedback / Suggestions
2009/11/25 Olaf van der Spek > > Yes, you're right. In a FCGI_GET_VALUES request, the backend can send > > arbitrary name-value-pairs. Unfortunately there is no standard way to tell > > the frontend that this feature is supported. Maybe, making the name (and > > expected value) of this name-value-pair configurable in mod_fcgid could > > be a reasonable way. > > Doesn't sound reasonable either. If you introduce such a feature, it > should simply be coordinated with other FastCGI stakeholders. You're right, again. I'm just wondering if such a change is likely to happen. Last update was 2002. I'd like to propose a change to the FastCGI stakeholders, if this makes any sense from a single, unrelated person. Edgar
Re: [mod_fcgid] Feedback / Suggestions
On Tue, Nov 24, 2009 at 11:08 AM, Olaf van der Spek wrote: > On Tue, Nov 24, 2009 at 5:03 PM, Jeff Trawick wrote: >>> What advantages does fcgid have over proxy_fcgi (except being ready)? >> >> integrated, on-demand process management > > How valuable is that? > In most cases a static number of backends seems fine. compared with mod_proxy_fcgi, the little or no required configuration/management of application processes with mod_fcgid makes it easier for newbies and/or casual users; at the same time it is sufficient for most sites, though perhaps with a little more config tweaking to allow higher spawn rates or larger pools per application > >>> mod_fcgid isn't in 2.2, right? >> >> mod_fcgid is actually not bundled with the HTTP server. It is >> released on its own cycle, and supports httpd 2.0.x, 2.2.x, and trunk >> (future httpd 2.4.x) with one delivery. > > Ah, nice. What's the reason it's not bundled though? I expect to see relatively high activity (compared with any particular bundled module) in mod_fcgid over the next 6 months or so. Given that, * bundling means considerable extra work to get fixes into both httpd trunk and the separate mod_fcgid tree that would continue to support httpd 2.0.x/2.2.x; that gets worse when httpd 2.4 is GA, as a fix could apply to httpd trunk, httpd 2.4.x branch, and the separate mod_fcgid tree * releasing of mod_fcgid fixes would be held up by the httpd release cycle > > In this case, I'd love to see support for TCP/IP backends too. > Shouldn't be too hard to implement. > >>> So what's the plan for 2.4? Have both of them? Or is mod_proxy_fcgi >>> expected to be not ready for 2.4? >> >> mod_fcgid will support 2.4. proxy-fcgi folk(s), care to speak up on your >> baby? > > Olaf >
Re: [mod_fcgid] Feedback / Suggestions
On Wed, Nov 25, 2009 at 12:17 PM, Edgar Frank wrote: >> Wouldn't it be better to have the backend tell the frontend that it >> supports this feature? Manual configuration should be avoided if >> possible. > > Yes, you're right. In a FCGI_GET_VALUES request, the backend can send > arbitrary name-value-pairs. Unfortunately there is no standard way to tell the > frontend that this feature is supported. Maybe, making the name (and expected > value) of this name-value-pair configurable in mod_fcgid could be a reasonable > way. Doesn't sound reasonable either. If you introduce such a feature, it should simply be coordinated with other FastCGI stakeholders. Olaf
Re: [mod_fcgid] Feedback / Suggestions
2009/11/26 Olaf van der Spek > On Wed, Nov 25, 2009 at 11:37 AM, Edgar Frank wrote: > > Maybe, in implementing this in mod_fcgid and making it configurable, > > Apache can serve more intelligent backends better. > > Wouldn't it be better to have the backend tell the frontend that it > supports this feature? Manual configuration should be avoided if > possible. Yes, you're right. In a FCGI_GET_VALUES request, the backend can send arbitrary name-value-pairs. Unfortunately there is no standard way to tell the frontend that this feature is supported. Maybe, making the name (and expected value) of this name-value-pair configurable in mod_fcgid could be a reasonable way. Edgar
Re: [mod_fcgid] Feedback / Suggestions
On Wed, Nov 25, 2009 at 11:37 AM, Edgar Frank wrote: > Maybe, in implementing this in mod_fcgid and making it configurable, Apache > can serve more intelligent backends better. Wouldn't it be better to have the backend tell the frontend that it supports this feature? Manual configuration should be avoided if possible. Olaf
Re: [mod_fcgid] Feedback / Suggestions
2009/11/25 Graham Dumpleton > 2009/11/25 Edgar Frank : > > While delving into the FCGI and CGI spec, I encountered another reason not > > to stream client data directly. CGI wants an explicitly set CONTENT_LENGTH > > and FCGI enforces than rather obsoletes this (last sentence in 6.2 of the > > FCGI spec). > > If the client sends for any reason a message body with no CONTENT_LENGTH > > set or CONTENT_LENGTH to be ignored as defined by RFC2616, you have to > > read the full message body to determine the correct content length > > which should be transferred to the backend. > > Things can get worse. Even if CONTENT_LENGTH is sent, if you have > requests with compressed content which is decompressed by mod_deflate, > the amount of content will not actually match what CONTENT_LENGTH says > there will be as it reflects how things are before content is > decompressed. I implied this by originally meaning "read the full message body through all input filters". Thanks for pointing this out. > Don't know about FASTCGI in general, but for WSGI (Python higher level > interface that can sit on CGI or FASTCGI) they have the stupid > requirement that you take CONTENT_LENGTH as being precise and that you > must not read more than CONTENT_LENGTH. If CONTENT_LENGTH isn't > provided, WSGI says you are supposed to take it as meaning no data. > > [...] > > Anyway, don't know if this is at all relevant to FASTCGI. As you point > out though, the CONTENT_LENGTH requirement does at least prevent > FASTCGI from handling chunked request content. WSGI specification has > same stupid limitation. At least if you adhere strictly to the spec, you have to do it this way for FastCGI, too. Although FastCGI provides the means to explicitly tell the backend when the end-of-stream is hit. I can't say if this is relevant in the real world, as there is still a chance of more intelligent backends. I'll try it with PHP as soon as I find time for this. Maybe, in implementing this in mod_fcgid and making it configurable, Apache can serve more intelligent backends better. Regards, Edgar
Re: [mod_fcgid] Feedback / Suggestions
2009/11/25 Edgar Frank : >> On Tue, Nov 24, 2009 at 05:07 PM, Jeff Trawick wrote: >> >>> 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 :) >> >> This is a reasonable feature; once streaming to the app is implemented >> this alternate mechanism can be enabled with a per-request envvar >> (e.g., SetEnv in the directory or location). > > Thanks for explaining this to me. > > While delving into the FCGI and CGI spec, I encountered another reason not to > stream client data directly. CGI wants an explicitly set CONTENT_LENGTH and > FCGI enforces than rather obsoletes this (last sentence in 6.2 of the FCGI > spec). > If the client sends for any reason a message body with no CONTENT_LENGTH set > or CONTENT_LENGTH to be ignored as defined by RFC2616, you have to read the > full message body to determine the correct content length which should be > transferred to the backend. Things can get worse. Even if CONTENT_LENGTH is sent, if you have requests with compressed content which is decompressed by mod_deflate, the amount of content will not actually match what CONTENT_LENGTH says there will be as it reflects how things are before content is decompressed. Don't know about FASTCGI in general, but for WSGI (Python higher level interface that can sit on CGI or FASTCGI) they have the stupid requirement that you take CONTENT_LENGTH as being precise and that you must not read more than CONTENT_LENGTH. If CONTENT_LENGTH isn't provided, WSGI says you are supposed to take it as meaning no data. For WSGI at least, means you can't have mutating input filters unless the input filter buffers up all the request content after doing what it does and recalculates CONTENT_LENGTH and sends through modified value. In practice input filters don't do this. Anyway, don't know if this is at all relevant to FASTCGI. As you point out though, the CONTENT_LENGTH requirement does at least prevent FASTCGI from handling chunked request content. WSGI specification has same stupid limitation. If things were defined so as to simply read until all input exhausted and for CONTENT_LENGTH really only to be used as a hint or in determining if original request body may be too large, wouldn't be such a pain. Graham
Re: [mod_fcgid] Feedback / Suggestions
> On Tue, Nov 24, 2009 at 05:07 PM, Jeff Trawick wrote: > >>> 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 :) > > This is a reasonable feature; once streaming to the app is implemented > this alternate mechanism can be enabled with a per-request envvar > (e.g., SetEnv in the directory or location). Thanks for explaining this to me. While delving into the FCGI and CGI spec, I encountered another reason not to stream client data directly. CGI wants an explicitly set CONTENT_LENGTH and FCGI enforces than rather obsoletes this (last sentence in 6.2 of the FCGI spec). If the client sends for any reason a message body with no CONTENT_LENGTH set or CONTENT_LENGTH to be ignored as defined by RFC2616, you have to read the full message body to determine the correct content length which should be transferred to the backend. Regards, Edgar
Re: [mod_fcgid] Feedback / Suggestions
> > (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. mod_proxy_fcgi already supports this use case completely, if it weren't for the two bugs I filed. While I see BZ#48273 as not-so-big issue, BZ#48272 presents a potential crash for the Apache process, which excludes it for production use. As far as I have understood the problem in BZ#48272, this is a real design issue in mod_proxy_fcgi, as it tries to stream the response by design while ap_scan_header_err_core wants the complete script output by design. > In the interim, is mod_fastcgi really that bad? Lets say, it works (fine) in terms that you can specify an external server. I took modifying mod_fastcgi into account to add the functionality for dynamic backend-switching, but refrained from doing so as the source code is made to work with Apache 1.x/2.0/2.2 with lots of #ifdefs, only partial APR support (handful of things are done on OS level) and additional Win32-kludges. Additionally, mod_fastcgi reads its backend servers at configuration time and access them at runtime readonly. Modifying this would mean to add thread safty to the source, if you want to use it in the worker mpm. Considering the sourcecode, this would be a bad job.
Re: [mod_fcgid] Feedback / Suggestions
On Tue, Nov 24, 2009 at 5:03 PM, Jeff Trawick wrote: >> What advantages does fcgid have over proxy_fcgi (except being ready)? > > integrated, on-demand process management How valuable is that? In most cases a static number of backends seems fine. >> mod_fcgid isn't in 2.2, right? > > mod_fcgid is actually not bundled with the HTTP server. It is > released on its own cycle, and supports httpd 2.0.x, 2.2.x, and trunk > (future httpd 2.4.x) with one delivery. Ah, nice. What's the reason it's not bundled though? In this case, I'd love to see support for TCP/IP backends too. Shouldn't be too hard to implement. >> So what's the plan for 2.4? Have both of them? Or is mod_proxy_fcgi >> expected to be not ready for 2.4? > > mod_fcgid will support 2.4. proxy-fcgi folk(s), care to speak up on your > baby? Olaf
Re: [mod_fcgid] Feedback / Suggestions
On Tue, Nov 24, 2009 at 10:50 AM, pqf wrote: >>> (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? I'm interested, but need to find adequate time. (I can certainly find time to review and help test somebody else's implementation.) > >>> >>> 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 :) This is a reasonable feature; once streaming to the app is implemented this alternate mechanism can be enabled with a per-request envvar (e.g., SetEnv in the directory or location).
Re: [mod_fcgid] Feedback / Suggestions
On Tue, Nov 24, 2009 at 10:58 AM, Olaf van der Spek wrote: > On Tue, Nov 24, 2009 at 4:47 PM, Jeff Trawick wrote: >>> What was the reason to import mod_fcgi again? Wasn't the ETA of >>> mod_proxy_fcgi too high? >> >> mod_fcgid was imported because it was >> >> * widely used >> * not actively maintained >> * httpd developers were willing to adopt it >> >> I felt that it was a nice addition particularly because it had a >> different approach to this important problem space compared with >> mod_proxy_fcgi. > > What advantages does fcgid have over proxy_fcgi (except being ready)? integrated, on-demand process management > >>> In the interim, is mod_fastcgi really that bad? >>> >>> I assume mod_fcgi wasn't developed without proper reason. >> >> So do I. (FWIW, I've put a lot of time into mod_fcgid and expect to >> continue doing so in the future.) >> >> The situation at hand seems to be >> >> * mod_proxy_fcgi promises to meet those requirements but falls short at >> present >> * mod_fcgid doesn't even try >> * mod_fastcgi implements at least some of those requirements and is mature > > mod_fcgid isn't in 2.2, right? mod_fcgid is actually not bundled with the HTTP server. It is released on its own cycle, and supports httpd 2.0.x, 2.2.x, and trunk (future httpd 2.4.x) with one delivery. > So what's the plan for 2.4? Have both of them? Or is mod_proxy_fcgi > expected to be not ready for 2.4? mod_fcgid will support 2.4. proxy-fcgi folk(s), care to speak up on your baby?
Re: [mod_fcgid] Feedback / Suggestions
On Tue, Nov 24, 2009 at 4:50 PM, pqf wrote: > 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? Doesn't it require an extra round trip? It's probably not too bad, but would be nice to avoid. Olaf
Re: [mod_fcgid] Feedback / Suggestions
On Tue, Nov 24, 2009 at 4:47 PM, Jeff Trawick wrote: >> What was the reason to import mod_fcgi again? Wasn't the ETA of >> mod_proxy_fcgi too high? > > mod_fcgid was imported because it was > > * widely used > * not actively maintained > * httpd developers were willing to adopt it > > I felt that it was a nice addition particularly because it had a > different approach to this important problem space compared with > mod_proxy_fcgi. What advantages does fcgid have over proxy_fcgi (except being ready)? >> >>> In the interim, is mod_fastcgi really that bad? >> >> I assume mod_fcgi wasn't developed without proper reason. > > So do I. (FWIW, I've put a lot of time into mod_fcgid and expect to > continue doing so in the future.) > > The situation at hand seems to be > > * mod_proxy_fcgi promises to meet those requirements but falls short at > present > * mod_fcgid doesn't even try > * mod_fastcgi implements at least some of those requirements and is mature mod_fcgid isn't in 2.2, right? So what's the plan for 2.4? Have both of them? Or is mod_proxy_fcgi expected to be not ready for 2.4? Olaf
Re: [mod_fcgid] Feedback / Suggestions
-- From: "Jeff Trawick" Sent: Tuesday, November 24, 2009 11:24 PM To: Subject: Re: [mod_fcgid] Feedback / Suggestions > 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 ;) > 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.
Re: [mod_fcgid] Feedback / Suggestions
On Tue, Nov 24, 2009 at 10:34 AM, Olaf van der Spek wrote: > On Tue, Nov 24, 2009 at 4:24 PM, Jeff Trawick wrote: >>> (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. > > What was the reason to import mod_fcgi again? Wasn't the ETA of > mod_proxy_fcgi too high? mod_fcgid was imported because it was * widely used * not actively maintained * httpd developers were willing to adopt it I felt that it was a nice addition particularly because it had a different approach to this important problem space compared with mod_proxy_fcgi. > >> In the interim, is mod_fastcgi really that bad? > > I assume mod_fcgi wasn't developed without proper reason. So do I. (FWIW, I've put a lot of time into mod_fcgid and expect to continue doing so in the future.) The situation at hand seems to be * mod_proxy_fcgi promises to meet those requirements but falls short at present * mod_fcgid doesn't even try * mod_fastcgi implements at least some of those requirements and is mature
Re: [mod_fcgid] Feedback / Suggestions
On Tue, Nov 24, 2009 at 4:24 PM, Jeff Trawick wrote: >> (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. What was the reason to import mod_fcgi again? Wasn't the ETA of mod_proxy_fcgi too high? > In the interim, is mod_fastcgi really that bad? I assume mod_fcgi wasn't developed without proper reason. Olaf
Re: [mod_fcgid] Feedback / Suggestions
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 clients. > (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.
