[Zope-Perl] Benefits of Zope multithreading

[Gisle Aas]

Jim Fulton <jim@digicool.com> writes:

> Gisle Aas wrote:
> > 
> > I am trying to evaluate what the current single lock that protects the
> > perl interpreter means to Zope's performance when running PerlMethods.
> > 
> > But, I don't really understand what the multithreading buys us in the
> > first place.  What is it that actually works better given the Zope is
> > multithreaded?  Is there any design documents I can look at?
> > 
> > The single python lock seems to mean that Zope can't really manage to
> > utilize multiple CPUs anyway and the Medusa framework should make sure
> > Zope can deal with multiple slow clients even without threads.
> 
> By being multi-threaded, Zope allows multiple requests to be handled
> simultaneously.  This is a big win, because a long-running request
> (e.g. database pack, catalog reindex, slow SQL query, etc.) won't
> block short requests.

Thanks for the answer!

As mentioned perl in "zope-perl" is currently protected by a single
lock (in fact similar to what python is), but perl itself is unaware
of this lock.  This means that the perl lock will not be released if
perl enters blocking or slow code.  No other thread can enter Perl
until the perl function entered by the first thread has returned.  The
python lock is released while we execute in perl mode so python code
can always execute concurrently with perl.

If there is a mix of PerlMethods where some take a long time to
execute and some are fast, then the fast ones will often become
blocked waiting to enter perl when the slow one is done.

If most web requests invoke some PerlMethod code and there are a few
slow PerlMethods then the whole server might block for extended
periods of time waiting for the slow request to finish.

The consequence of this is really that PerlMethods should not be used
for anything that will not return fast.  This probably also make the
ZDBI_DA not very usable.

I'm now investigating if there is a way to fix this.  If we make sure
references to perl data do not escape to python (that means not
providing the "perl ref objects") then we can probably let there be
separate perl interpreters for each thread.  Then we don't need any
perl lock at all and PerlMethods will be able to run in true parallel
on multiple CPUs.  When these PerlMethods call back to python in order
to invoke methods on the Zope objects passed as argument(s) they will
be sequentialised though.

Regards,
Gisle

> Under normal situations, where effectively all the computation is
> done in Python, then Python's global interpreter lock prevents us
> from taking good advantage of multiple processors. Oh well, we still
> get concurrency, which is the main thing we want.
> 
> Note that in applications that spend a good bit of time
> outside the Python interpreter, lots of computation is not
> bound by the global interpreter lock. For example, a Zope app
> that makes alot of calls to an RDBMS gets alot of advantage.
> A thread can be executing the interpreter while other threads
> are blocking on database calls.
> 
> Still, if we want to take advantage of multiple processors, we'll
> use ZEO to run multiple Zope processes.
> 
> Jim