Hi,

I spoke a little too soon, there is one problem.

mod_fcgid correctly uses the VirtualHost as one of the unique inputs
for each backend daemon.

(Sidenote: This virtualhost code is *only* present in the unix process
manager, which means there is a separate bug/issue in the win32
process manager code)

And while this is technically correct, it causes a problem for
*.apache.org.  As you know, we have something like 70+ TLPs.  While
they are all running the same FastCGI script, each one of these TLPs
has their own subdomain, and therefore mod_fcgid is treating their
scripts as different process groups.

Since we have so many TLPs (go us!), we were looking at roughly 300
mirror.fcgi processes running on our production web server, while if
we were to 'fake' it under one vhost, I believe it would only be 10.

Index: fcgid_pm_unix.c
===================================================================
--- fcgid_pm_unix.c     (revision 817154)
+++ fcgid_pm_unix.c     (working copy)
@@ -434,7 +434,7 @@
     command->deviceid = deviceid;
     command->inode = inode;
     command->share_grp_id = share_grp_id;
-    command->virtualhost = r->server->server_hostname;
+    command->virtualhost = "apache.org's setup is awesome";

     /* Update fcgid_command with wrapper info */
     command->wrapperpath[0] = '\0';


While, this is obviously a terrible thing for a general purpose
module, I would like to propose that we add a 'FCGIIgnoreVirtualHost'
configuration option, which would set the vhost field to a constant
value, so FCGI processes would be shared between virtual hosts.

ps, patch is deployed to apache.org right now.... :)
.....
> BTW, we are now running mod_fcgid trunk in production for www.apache.org.
>
> wiki.apache.org (MoinMoin powered) is now running in FastCGI mode, via
> mod_fcgid.
>
> I also hacked up all of the download,cgi/mirror.cgi scripts, so they
> are running via fastcgi too ( <http://httpd.apache.org/download.cgi>,
> <http://www.apache.org/dyn/mirrors/mirrors.cgi>, etc)
>
> eating the dogfood quite well right now... :)
>
> -Paul
>

Reply via email to