[Web-SIG] multi-threaded or multi-process wsgi apps

[Graham Dumpleton]

On 30/11/2007, Chris Withers <chris at simplistix.co.uk> wrote:
> Graham Dumpleton wrote:
> > package. You can if appropriate even use a combination of both modes.
>
> So these would just be seperate sections in apache's config files?

For an example see:

  http://blog.dscpl.com.au/2007/09/parallel-python-discussion-and-modwsgi.html

You just need to use mod_wsgi WSGIProcessGroup directive in
appropriate Directory or Location context to indicate that that WSGI
application or subset of an application should be delegated to a
different daemon process.

> > For example, run Django in embedded mode for best performance,
>
> Why does this give best performance?

For some discussion on this see the following, including comments:

  http://blog.dscpl.com.au/2007/07/web-hosting-landscape-and-modwsgi.html

In short, everything is done in the first process to accept the
request. There is no proxying to a secondary process across another
socket connection. Also, Apache has the ability to create additional
processes on demand as server load increases. Proxy based solutions,
unless proxying to Apache as a backend, often use a fixed number of
backend processes and have no way of scaling up to meet demand by
starting up new processes automatically.

As explained in the blog it is a trade off. You get extra speed, but
there are other issues to contend with which make running multiple
applications in embedded mode at the same time problematic. But then
if wanting maximum speed you would have dedicated the one server to
that application and so the issues aren't really a problem.

> > but
> > delegate a Trac instance to run in daemon mode so it is separated out
> > of Apache child processes, there being various reasons with Trac why
> > you might want to do that.
>
> Such as?

Python bindings for subversion need to run in main Python interpreter
as they aren't written to work properly within a secondary Python sub
interpreter. One can still force this when run in embedded mode, but
Trac can chew up a lot of memory over time, especially if GoogleBot
decides to browse every revision of your code through the Trac source
browser. Yes one should block search engines from such searching, but
even so, can be beneficial to use daemon mode as then takes main bloat
out of Apache child processes and allows one to set more aggressive
value for maximum requests so that processes are recycled and memory
reclaimed on a regular basis and reset back to idle level.

> > Each process can if necessary have multiple Python sub interpreters,
> > and is not limited to just one. This would be used where you need to
> > run multiple applications in the same process but with sub
> > interpreters being used as a means of separating them so they don't
> > interfere with each other.
>
> Wow, I didn't even know this was possible.. what does
> dirt-simple-hello-world-like python that does this look like?

The Python code looks exactly the same, you don't need to change
anything. In mod_wsgi it defaults to automatically using a separate
sub interpreter for each WSGI application script file. If your WSGI
applications don't clash and you want to make them run in the same
interpreter to avoiding loading multiple copies of modules into
memory, just need to use the mod_wsgi WSGIApplicationGroup directory.
For example:

  <VirtualHost *:80>
  WSGIApplicationGroup %{SERVER}
  ...
  </VirtualHost>

This will result in all WSGI applications running under a specific
virtual server (on port 80/443) using the same Python sub interpreter.

More details in:

  http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines
  http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives

> > Thus generally better for each process to create its own connections
> > etc. Reading of actual file configuration is generally a quite minor
> > overhead in the greater scheme of things.
>
> You haven't used zope, right? ;-)

Not since last century some time. :-)

Graham