httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Dumpleton <graham.dumple...@gmail.com>
Subject Re: [mod_fcgid] How to share between vhosts (and extensions)
Date Wed, 23 Sep 2009 23:34:58 GMT
FWIW, the Python specific hosting module called mod_wsgi for Apache
implements named daemon process groups, with ability to control how
WSGI applications are delegated to which process group. This includes
being able to optionally have process group selected based on value of
ENV value set by mod_rewrite. Various directives can optionally be
used to limit which process groups can be delegated when using this.

Anyway, not necessarily relevant but may still be of interest. Links
to some of the documentation are:

  http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIProcessGroup
  http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess
  http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIRestrictProcess

Graham

2009/9/23 Rainer Jung <rainer.jung@kippdata.de>:
> Sorry for the long mail, especially in case all is well-known.
>
> While looking for the right way to implement something like FCGIDGroup I
> stumbled about something a bit strange in mod_fcgid.
>
> When looking for an appropriate existing process to handle a request the
> following data is used by mod_fcgid:
>
> - inode
>  inode num of the wrapper if one is used,
>  of the request filename otherwise
> - deviceid
>  device id of the wrapper if one is used,
>  of the request filename otherwise
> - share_grp_id
>  Always 0 if no wrapper is used,
>  -1 for one of the auth wrappers,
>  otherwise an incrementing id that is
>  unique across each wrapper with the same path
>  (but different vhosts or even only different extensions)
>  ids between different paths can overlap
> - virtualhost: the pointer (!) to
>  r->server->server_hostname
> - uid: retrieved via ap_run_get_suexec_identity
> - gid: retrieved via ap_run_get_suexec_identity
>
> If no process is found, a new one is created and carries the above data
> coming from the request (and wrapper) which ran when it was created.
>
> Going a bit through the history of mod_fcgid, it seems that share_grp_id
> was added to support a directive FCGIWrapperGroup (sic!). Later the
> directive was removed, and the id was automatically incremented to
> ensure separation.
>
> Again later there was a bug w.r.t. incomplete isolation of the default
> env between vhosts, so virtualhost was added, but seems only necessary
> for the non-wrapper case.
>
> It seems there's some potential for improvement concerning sharing of
> fastcgi applications.
>
> 1) Non-wrapper case
>
> The applications are given by the filenames the requests resolve to. So
> the most likely thing that could happen, is that someone wants to share
> the process pools for those between vhosts. I guess for this it would be
> enough to add FCGIDGroup. It would be optionally used once in vhosts to
> set a symbolic name, which will be used to seperate the pools between
> vhosts instead of the server_hostname. By choosing the same FCGIDGroup
> in several vhosts, one can share the process pool.
>
> 2) Wrapper case
>
> The wrapper is configured via its path name and the optional extension
> it applies to. At the moment independent pools are used for different
> vhosts, but also (!) for different extensions.
>
> So if we would add FCGIDGroup to a vhost, it would stop the extension
> separation. Another possibility would be, to apply FCGIDGroup only to
> the non-wrapper case and add some syntax to FCGIWrapper to allow
> expressing, which group it belongs to. Unfortunately that directive
> already has two optional arguments, one can be detected, because it
> starts with a dot, the other one is the fixed string "virtual". The
> syntax might get ugly, if we need to safely distinguish three optional
> arguments
>
> Something like
>
> FCGIDWrapper wrapperpath [groupname] [.extension] [+flag ...]
>
> and the only flag implemented at the moment is "virtual".
>
> Regards,
>
> Rainer
>
>

Mime
View raw message