Python does not play well with others

[John Nagle]

Graham Dumpleton wrote:
> On Feb 4, 1:05 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> 
>>"Paul Boddie" <p... at boddie.org.uk> writes:
>>
>>>Probably the biggest inhibitor, as far as I can see, has been the
>>>server technology chosen. Many hosting providers have historically
>>>offered no better than CGI for Python, whilst PHP runs within Apache
>>>itself, and it has previously been stated that mod_python has been
>>>undesirable with regard to isolating processes from each other.
>>>Consequently, a number of Python people seem to have held out for
>>>other "high performance" solutions, which various companies now offer.
>>
>>Your point that shared hosting with Python isn't so easy because of
>>insufficient isolation between apps is valid.  Maybe Python 3.0 can do
>>something about that and it seems like a valid thing to consider while
>>fleshing out the 3.0 design.
> 
> 
> To clarify some points about mod_python, since these posts do not
> properly explain the reality of the situation and I feel people are
> getting the wrong impression.
> 
> First off, when using mod_python it is possible to have it create
> multiple sub interpreters within each Apache child process.

     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.

     FastCGI, though, can get all the CPUs going.  It takes more
memory, though, since each instance has a full copy of Python
and all the libraries in use.

     (FastCGI is a straightforward transaction processing engine.
Each transaction program is launched in a separate process, and,
once done with one transaction, can be used to do another one
without reloading.  When things are slow, the extra transaction processes
are told to exit; when load picks up, more of them are forked.
Security is comparable to CGI.)

					John Nagle