Home / server / Questions / 500245
Accepted
rorycl
Asked: 2013-04-18 07:31:08 +0800 CST

mod_wsgi : share daemon processes between vhosts

  • 772

I have many sites each using the same 5 Django applications (with local settings), hosted on Apache. At present each site app has its own config as follows:

WSGIDaemonProcess api_example threads=15 maximum-requests=2000
WSGIProcessGroup api_example
WSGIScriptAlias /api /var/www/sites/example/api/site.wsgi

Is it possible to share daemons between vhosts, but keep the local settings active? My aim is to save memory, and reduce the number of Apache processes launched to service requests (several of these apps are management/support consoles that are only used occasionally).

-- edit --

As Graham Dumpleton sets out here: mod_wsgi daemon mode - WSGIDaemonProcess per virtual host configuration?, it should be possible to "reach across to daemon process definition in prior virtual host so long [as it has the] same server name." Note that, as Graham points out, the WSGIApplicationGroup directive will have to be adjusted from the default, probably to %{GLOBAL} or %{ENV:variable}.

I'm not sure how to "use" server-level declarations within a vhost. Is it possible to use a server-level daemon with local settings?

apache-2.2

1 Answers

  1. Best Answer

    The answer to the above questions, summarised as:

    1. is it possible to share wsgi daemons between vhosts?
    2. is it possible to keep each application in each vhost separated (while sharing daemons) so that local settings are in force ?
    3. if 1. and 2. are possible, can one restart/shutdown daemons to save memory?

    The answer to all of the above is Yes.

    Here is an example configuration, using Debian's apache2 config as an example:

    ...
# Include definition of wsgi_daemons above the vhost configs
Include /etc/apache2/wsgi_daemons/

# Include the virtual host configurations:
Include /etc/apache2/sites-enabled/
...

    Define some wsgi daemons, eg:

    WSGIDaemonProcess wsgi_support threads=5 \
display-name=wsgi_support inactivity-timeout=600

    In your vhost config, define a block along the following lines:

    <Location /support/console>
    WSGIProcessGroup wsgi_support
    WSGIApplicationGroup <this_vhost>_support
    # WSGIApplicationGroup %{GLOBAL} does not work!!!
</Location>
WSGIScriptAlias /support/ /var/www/<this_vhost>/support/site.wsgi

    What this does:

    • A daemon with the name "wsgi_support" will be started when Apache starts/is restarted
    • When <this_vhost>'s support app is accessed, it will attach to the wsgi_support daemon process as this is defined by the WSGIProcessGroup directive
    • To ensure that <this_vhosts>'s copy of the app is running in its own namespace (which is vital if you are running Django apps for instance, because settings are only evaluated on startup) the vhost is given its own WSGIApplicationGroup. This causes the master daemon to spawn a sub-interpreter for <this_vhost>'s app.
    • Finally, the timeout directive causes the daemon to restart after the stated period of inactivity, releasing memory used by subinterpreters. This is perfect for little-used apps like support consoles.

    Please read the excellent docs at http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives.

    Two things tripped me up initially: not defining the wsgi_daemons in the right place (which was pretty stupid) and not realising that WSGIProcessGroup directives point to WSGIDaemonProcess definitions.

    • 1