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

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Brewer wrote:
> Chris Withers wrote:
>> Right, I'm curious as to how wsgi applications end up being
>> multi-threaded or multi-process and if they are, how they share
>> resources such as databases and configuration.
>>
>> There's a couple of reasons I'm asking...
>>
>> The first was something Chris McDonough said about one ofthe issues
>> they're having with the repoze project: when using something like
>> mod_wsgi, it's the first person to hit each thread that takes the hit
>> of loading the configuration and opening up the zodb. Opening the
> ZODB,
>> in particular, can take a lot of time. How should repoze be structured
>> such that all the threads load their config and open their databases
>> when apache is restarted rather than when each thread is first hit?
> 
> If I were coding it, repoze would use a database connection pool that is
> populated at (sub)process startup. The main thread is the only one
> "loading config". That avoids any waits during the HTTP request, so your
> req/sec rate will go way up. It also allows the process to fail fast in
> the event of unreachable databases, so such errors during deployment
> will be found sooner and will be easier to debug if they occur outside
> of an HTTP request.

Zope has already done this for years.  The issue is that, under
mod_wsgi, one of the most attractive ways to run Zope / repoze is using
'daemon mode', which allows for separate, long-running processes to
handle the application code.

*Each* of these processes is going to have its own connection pool,
which is less than ideal (from the point of view of RAM usage / cache
coherence);  however, isolating the application in separate process(es)
has other large benefits (improved SMP behavior, for one, as well as
allowing different applications to run with different configurations).


> It's like a stage production: you don't ask your actors to buy props and
> build the set during the show--instead, you buy/build all that and
> script/debug/automate the hell out of it before you have an audience.
> All long-running servers are a lot like that; do everything you can
> before the first request to make absolutely sure nothing slows or stops
> you during showtime.
> 
>> The second is a problem I see an app I'm working on heading towards.
>> The app has web-alterable configuration, so in a multi-threaded and
>> particular multi-process environment, I need some way to get the other
>> threads or processes to re-read their configuration when it has
>> changed.
> 
> In a multithreaded environment, I recommend apps read config only at
> process startup, parse the entries and use them to modify live objects,
> and then throw away the config. Then, if you need to make changes to
> settings while live, you just modify the live objects in the same way
> the config parsing step did (and then modify the config file only if
> desired). That avoids having to re-read the whole config file for each
> potential change. In a multiprocess environment, you can notify other
> process with any of various forms of IPC or shared state mechanisms

People want to be able to edit the config file and HUP the server, in
order to ensure that any changes they make persist across restarts;
requiring them to change it in two places (a "control panel" as well as
the config file) is pretty much a non-starter (pun intended :).


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHTIRK+gerLs4ltQ4RAt26AJ4yqmjtkHJM0uX4twIP66wAf+CdAwCgpK0T
rrtH9FAWKzN2vyti+Pxmke4=
=2B/f
-----END PGP SIGNATURE-----