[Twisted-Python] Re: twisted application server
andreas at kostyrka.org
Fri Mar 7 07:44:02 EST 2008
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.
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
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://twistedmatrix.com/pipermail/twisted-python/attachments/20080307/fed01e1f/attachment.pgp
More information about the Twisted-Python