-----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 [EMAIL PROTECTED] 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----- _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
