[Zope] zserver-threads

[Floyd May]

On 1/31/06, Jake <jake at zopezone.com> wrote:
>
> Am I gleaming from that that you are proposing a less-is-more approach to
> threads?
>
> Here is what I have been using:
> - Zope 2.7.8 (Plone 2.1.2)
> - RH Linux
> - AMD Athlon 64 3200+ 2.0 GHz
> - 2GB DDR RAM
> - 120,000 hits a day
> - 392,036 objects in database
> - 2 threads
> - 100,000 object cache size
>
> This seems to eat up about half of the RAM on the server.
>
> Would one thread but double the cache size do better?
>
> Jake
> _______________________
> http://www.ZopeZone.com
>
>
> On Tue, January 31, 2006 2:40 pm, Dieter Maurer said:
> > Jens Vagelpohl wrote at 2006-1-31 15:07 +0000:
> >>On 31 Jan 2006, at 15:01, Jake wrote:
> >>
> >>> http://plone.org/documentation/how-to/threads-vs-cache-size
> >>
> >>That article contains little information to back up the conclusions,
> >>and some of it is patently wrong. Another case of hearsay and half-
> >>thruths being propagated by well-meaning but uninformed parties.
> >
> > There is a convincing example (I think from Matt Kromer) what
> > happens to "mean response time" when the number of threads
> > is increased from 1 to 2:
> >
> >   Assume you have 2 units of work. If you have a single
> >   thread, 1 unit is done, then the second. The
> >   mean response time is (1 + 2) / 2 = 1.5.
> >
> >   Now assume you have two threads (but a single processor).
> >   Both threads work (quasi) parallel but have only half of the
> >   processor power. Both will take 2 time units to perform
> >   their unit of work. The mean response time is (2 + 2) / 2 = 2.
> >
> > You get the same ratios whenever you double the number of threads
> > (but keep the number of processors and all your work is CPU bound).
> >
> >
> > Things become more difficult when you have a mix of very small
> > requests and very long requests. You then may want a higher
> > level of concurrency to not let the small requests being
> > blocked by the long ones.
> >
> >
> > --
> > Dieter
> > _______________________________________________
> > Zope maillist  -  Zope at zope.org
> > http://mail.zope.org/mailman/listinfo/zope
> > **   No cross posts or HTML encoding!  **
> > (Related lists -
> >  http://mail.zope.org/mailman/listinfo/zope-announce
> >  http://mail.zope.org/mailman/listinfo/zope-dev )
> >
>
>
> _______________________________________________
> Zope maillist  -  Zope at zope.org
> http://mail.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists -
> http://mail.zope.org/mailman/listinfo/zope-announce
> http://mail.zope.org/mailman/listinfo/zope-dev )
>
>
I would recommend exploring ZEO and Squid if you're *this* worried about
performance.  There's only so much that one machine can do.  If I understand
the Zope framework, the idea is that read-to-write ratio for the ZODB is
going to be much greater than one, meaning that there are going to be a lot
more reads than writes.  In this case, having some load balancing and ZEO
client caching will make overall performance faster.  However, if you're
doing lots of writing to the ZODB, you'll probably need to explore ZEO even
more in the area of mounting different ZODBs at different places in your ZEO
clients' trees.

Like some of the other people said, you probably should just tune it as
needed.  It's also a Bad Thing to be running your servers at or near
capacity; you should leave plenty of headspace for usage spikes.  I've
certainly run into situations where Zope stuff was processor-bound and
slowing everything down, but the RAM wasn't even 25% full.  In cases like
this, more zserver threads (or more ZEO clients) helps even things out.
YMMV.

--
Floyd May
Senior Systems Analyst
CTLN - CareerTech Learning Network
fmay at okcareertech.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/zope/attachments/20060131/7e97550f/attachment.htm