Python does not play well with others

sjdevnull at yahoo.com sjdevnull at yahoo.com
Mon Feb 5 16:57:48 EST 2007


On Feb 5, 12:52 pm, John Nagle <n... at animats.com> wrote:
> sjdevn... at yahoo.com wrote:
> > John Nagle wrote:
>
> >>Graham Dumpleton wrote:
>
> >>>On Feb 4, 1:05 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
>
> >>>>"Paul Boddie" <p... at boddie.org.uk> writes:
> >>     Realistically, mod_python is a dead end for large servers,
> >>because Python isn't really multi-threaded.  The Global Python
> >>Lock means that a multi-core CPU won't help performance.
>
> > The GIL doesn't affect seperate processes, and any large server that
> > cares about stability is going to be running a pre-forking MPM no
> > matter what language they're supporting.
>
>    Pre-forking doesn't reduce load; it just improves responsiveness.
> You still pay for loading all the modules on every request.

No, you don't.  Each server is persistent and serves many requests--
it's not at all like CGI, and it reuses the loaded Python image.

So if you have, say, an expensive to load Python module, that will
only be executed once for each server you start...e.g. if you have
Apache configured to accept up to 50 connections, the module will be
run at most 50 times; once each of the 50 processes has started up,
they stick around until you restart Apache, unless you've configured
apache to only serve X requests in one process before restarting it.
(The one major feature that mod_python _is_ missing is the ability to
do some setup in the Python module prior to forking.  That would make
restarting Apache somewhat nicer).

The major advantage of pre-forking is that you have memory protection
between servers, so a bug in one won't take down the whole apache
server (just the connection(s) that are affected by that bug).  Most
shared hosting providers use pre-forking just for these stability
reasons.

A nice side effect of the memory protection is that you have
completely seperate Python interpreters in each process--while each
one is reused between connections, they run in independent processes
and the GIL doesn't come into play at all.




More information about the Python-list mailing list