Graham Dumpleton wrote:
> On Feb 4, 1:05 pm, Paul Rubin <http://[EMAIL PROTECTED]> wrote:
>
>>"Paul Boddie" <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
