[Zope] Priority of processes in Zope
oliver.erlewein@sqs.de
oliver.erlewein@sqs.de
Tue, 19 Feb 2002 18:16:01 +0100
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C1B969.1AD49A90
Content-Type: text/plain;
charset="iso-8859-1"
Hi Matthew
Thanx for your answer.
I'm still batteling furiously with Solaris and Zope. As opposed to Win NT /
MacOS X / Linux Solaris seems to be running Zope in a single thread. For
details see the zope-news-thread on "threading, dtml and performance". You
can check this by running a complex dtml-method and trying to access anythin
else on that site at the same time. My system freezes for as long as the
huge task takes.
My Solaris servers:
Zopeserver 1 (Sun R280/4GB Ram/4 CPU's/ Solaris 2.8 - I think /not
dedicated)
Pystone(1.1) time for 10000 passes = 2.03
This machine benchmarks at 4926.11 pystones/second
Zopeserver 2 (PIII 1Ghz DELL 19"/512Mb Ram/1 CPU/ Solaris 2.7/dedicated
Zope)
Pystone(1.1) time for 10000 passes = 0.85
This machine benchmarks at 11764.7 pystones/second
That sortof justifies your hunch on what is cheaper (the sun is about 15
times the price of the DELL rack). If you use the server for other programs
aswell then the Intel looses the cutting edge due to the one processor.
Oliver Erlewein
> Hi Oliver,
>
> Threading priority is a dynamic computation by the Solaris
> scheduler --
> the thread with the lower priorities are dispatched first -- but once
> you get dispatched your priority raises if you finish your timeslice
> without entering a wait state (well, that may be a simplification).
>
> Because Python is controlled by a large central lock, only one thread
> can be doing any useful work most of the time. There are
> exceptions to
> this rule, but most of Zope is compute-bound, not IO-bound. The net
> effect is that you rarely see more than a few threads in Zope
> doing work.
>
> More interesting to note is that the performance of Zope is
> pretty much
> linear with the results of the "pystone" benchmark. So, if you run
>
> python /usr/local/lib/python2.1/test/pystone.py
>
> you might get a number like
>
> blade(3)$ python /usr/local/lib/python2.1/test/pystone.py
> Pystone(1.1) time for 10000 passes = 1.77
> This machine benchmarks at 5649.72 pystones/second
>
> That's my results on a SunBlade 100 (500 Mhz UltraSPARC IIe).
>
> Its worthwhile noting that I get the following result on a
> 500 Mhz Intel
> Celeron:
>
> djinn(12)$ python2.1
> /usr/local/python-2.1.2/lib/python2.1/test/pystone.py
> Pystone(1.1) time for 10000 passes = 1.47
> This machine benchmarks at 6802.72 pystones/second
>
> from which you may draw two conclusions: 1) Gcc on SPARC
> doesn't emit
> the best bytecodes, and 2) Intel CPUs run Python more
> cost-effectively
> than SPARC chipsets do.
>
> --
> Matt Kromer
> Zope Corporation http://www.zope.com/
>
>
>
------_=_NextPart_001_01C1B969.1AD49A90
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>Re: [Zope] Priority of processes in Zope</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Hi Matthew</FONT>
</P>
<P><FONT SIZE=3D2>Thanx for your answer.</FONT>
</P>
<P><FONT SIZE=3D2>I'm still batteling furiously with Solaris and Zope. =
As opposed to Win NT / MacOS X / Linux Solaris seems to be running Zope =
in a single thread. For details see the zope-news-thread on =
"threading, dtml and performance". You can check this by =
running a complex dtml-method and trying to access anythin else on that =
site at the same time. My system freezes for as long as the huge task =
takes.</FONT></P>
<P><FONT SIZE=3D2>My Solaris servers:</FONT>
</P>
<P><FONT SIZE=3D2>Zopeserver 1 (Sun R280/4GB Ram/4 CPU's/ Solaris 2.8 - =
I think /not dedicated)</FONT>
<BR><FONT SIZE=3D2>Pystone(1.1) time for 10000 passes =3D 2.03</FONT>
<BR><FONT SIZE=3D2>This machine benchmarks at 4926.11 =
pystones/second</FONT>
</P>
<P><FONT SIZE=3D2>Zopeserver 2 (PIII 1Ghz DELL 19"/512Mb Ram/1 =
CPU/ Solaris 2.7/dedicated Zope)</FONT>
<BR><FONT SIZE=3D2>Pystone(1.1) time for 10000 passes =3D 0.85</FONT>
<BR><FONT SIZE=3D2>This machine benchmarks at 11764.7 =
pystones/second</FONT>
</P>
<P><FONT SIZE=3D2>That sortof justifies your hunch on what is cheaper =
(the sun is about 15 times the price of the DELL rack). If you use the =
server for other programs aswell then the Intel looses the cutting edge =
due to the one processor.</FONT></P>
<P><FONT SIZE=3D2>Oliver Erlewein</FONT>
</P>
<P><FONT SIZE=3D2>> Hi Oliver,</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Threading priority is a dynamic computation by =
the Solaris </FONT>
<BR><FONT SIZE=3D2>> scheduler -- </FONT>
<BR><FONT SIZE=3D2>> the thread with the lower priorities are =
dispatched first -- but once </FONT>
<BR><FONT SIZE=3D2>> you get dispatched your priority raises if you =
finish your timeslice </FONT>
<BR><FONT SIZE=3D2>> without entering a wait state (well, that may =
be a simplification).</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Because Python is controlled by a large central =
lock, only one thread </FONT>
<BR><FONT SIZE=3D2>> can be doing any useful work most of the =
time. There are </FONT>
<BR><FONT SIZE=3D2>> exceptions to </FONT>
<BR><FONT SIZE=3D2>> this rule, but most of Zope is compute-bound, =
not IO-bound. The net </FONT>
<BR><FONT SIZE=3D2>> effect is that you rarely see more than a few =
threads in Zope </FONT>
<BR><FONT SIZE=3D2>> doing work.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> More interesting to note is that the =
performance of Zope is </FONT>
<BR><FONT SIZE=3D2>> pretty much </FONT>
<BR><FONT SIZE=3D2>> linear with the results of the =
"pystone" benchmark. So, if you run</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> python =
/usr/local/lib/python2.1/test/pystone.py</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> you might get a number like</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> blade(3)$ python =
/usr/local/lib/python2.1/test/pystone.py</FONT>
<BR><FONT SIZE=3D2>> Pystone(1.1) time for 10000 passes =3D =
1.77</FONT>
<BR><FONT SIZE=3D2>> This machine benchmarks at 5649.72 =
pystones/second</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> That's my results on a SunBlade 100 (500 Mhz =
UltraSPARC IIe). </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Its worthwhile noting that I get the following =
result on a </FONT>
<BR><FONT SIZE=3D2>> 500 Mhz Intel </FONT>
<BR><FONT SIZE=3D2>> Celeron:</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> djinn(12)$ python2.1 </FONT>
<BR><FONT SIZE=3D2>> =
/usr/local/python-2.1.2/lib/python2.1/test/pystone.py</FONT>
<BR><FONT SIZE=3D2>> Pystone(1.1) time for 10000 passes =3D =
1.47</FONT>
<BR><FONT SIZE=3D2>> This machine benchmarks at 6802.72 =
pystones/second</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> from which you may draw two conclusions: =
1) Gcc on SPARC </FONT>
<BR><FONT SIZE=3D2>> doesn't emit </FONT>
<BR><FONT SIZE=3D2>> the best bytecodes, and 2) Intel CPUs run =
Python more </FONT>
<BR><FONT SIZE=3D2>> cost-effectively </FONT>
<BR><FONT SIZE=3D2>> than SPARC chipsets do.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> -- </FONT>
<BR><FONT SIZE=3D2>> Matt Kromer</FONT>
<BR><FONT SIZE=3D2>> Zope Corporation <A =
HREF=3D"http://www.zope.com/" =
TARGET=3D"_blank">http://www.zope.com/</A> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C1B969.1AD49A90--