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

[Tres Seaver]

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

Chris Withers wrote:

> I hope I have the right list, if not please point me in the right 
> direction...
> 
> Likewise, if there are good docs that cover all of this, please send me 
> their way ;-)
> 
> 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?

Note first that we use mod_wsgi's "daemon"-mode exclusively, which
implies creating one or more dedicated subprocesses for each "process
group" defined in the Apache config.

In that mode, Apache may create new subprocesses at any time, and may
destroy old ones (e.g., after reaching a max-requests threshhold).  The
real issue isn't opening the ZODB;  it is populating a new connection
cache.  A second issue for multi-process configurations is doing all the
product initialization dance (for a Zope2 app) or processing ZCML (for
either Zope2 or Zope3).  The "frist hit slow" problem is intrinsic to
any lazy + scalable system.

> 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.
> 
> Hope you guys can help!

Making the ZODB connection pool sharable across processes doesn't seem
feasible.  I have toyed with the idea of creating a sharable "L2" cache
(the ZEO client cache), perhaps using something like memcache for the
backing store.  In that configuration, all running appservers would
share the same "pickle cache", which could be distributed across a bunch
of servers;  they would still have to load the pickles as objects into
their "LI" cache before using them.


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

iD8DBQFHSvu0+gerLs4ltQ4RAn3eAJ9GrFNlbDeBZ+hShFlUUjclkWuJmwCeLQqm
r6dTsrjtbI/QSre84ZR2glk=
=OzgY
-----END PGP SIGNATURE-----