On Thu, Oct 29, 2009 at 9:16 AM, Akins, Brian <[email protected]> wrote: > With all the discussion of mod_fcgid lately (I admit, I did not read all the > threads, so forgive me if we already discussed this), I was wondering if a > different approach would be better.
Thus far the mod_fcgid activity has been focused on resolving some existing problems and establishing the new home. There are some new configuration capabilities though. There's a fair amount of mechanical work to make it a well behaved module overall. > I know at one time there was work on a mod_proxy_fastcgi. The current trend > in "other webservers" seems to do the proxying inside the webserver and > using a separate small process manager - something like spawn-fcgi or > supervisord. > > So, we could have configs something like: > > ProxyPass /myapp fastcgi:///path/to/my.sock max=6 ... > > And should easily be able to do fasctcgi over tcp, etc. > > This should, hopefully, simplify the "in httpd" code. AFAIK mod_proxy_fcgi in trunk actually works, though I haven't tried it. Just my 2cents: In general the idea of using mod_proxy_fcgi + separate process manager works for me, though I am more anxious at the moment to try to help the relatively large user base of mod_fcgid users adopt the new 2.3.x series, and help see that whatever mod_fcgid 2.2 patches have been floating around since 2007 get properly evaluated and resolved as appropriate. There has been some interest expressed on this list from the mod_fcgid user community to manage processes differently (e.g., independent of load); in general, I'd like to see the proxy+process mgr solution support requirements that would otherwise twist mod_fcgid in new directions.
