[Twisted-Python] Re: twisted application server

[Andreas Kostyrka]

Actually, on a modern system like Linux, if you fork, the process share
memory as long it's not written too (Copy-on-Write).

This means, that if you'd fork off your process pool from your
application, forking should have minimal impact. Even writing it as a
standalone process means memory usage of one Python interpreter, plus
minimal usage in the forked processes.

Andreas

Am Donnerstag, den 06.03.2008, 09:35 -0800 schrieb Don Dwiggins:
> glyph at divmod.com wrote:
> > The other reason is that adbapi is old.  If we were going to implement 
> > something like ADBAPI today, we'd probably write a process pool first, 
> > but adbapi was written as a quick hack to get some database integration 
> > a long time ago.
> > 
> > The only caveat is that additional Python interpreters take up more RAM 
> > than additional threads.  If the database processes are doing any heavy 
> > CPU lifting though, this cost could well be worth it.
> 
> I'm just getting started with an XMLRPC server that uses adbapi.  This 
> satisfies my curiosity as to why it was threaded.  Now assuming that, 
> for my application, the "heavy lifting" is done by the DB engine itself, 
> is there any good reason to dig into implementing a process pool?  (I'm 
> thinking of the future here, as the server begins to grow more 
> functionality.  Right now, my main concern is not to block multiple 
> simultaneous requests from clients.)
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://twistedmatrix.com/pipermail/twisted-python/attachments/20080307/fed01e1f/attachment.pgp