Am I gleaming from that that you are proposing a less-is-more approach to
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?
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:
>>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.
> Zope maillist - Zope@zope.org
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://mail.zope.org/mailman/listinfo/zope-dev )
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -
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.
Senior Systems Analyst
CTLN - CareerTech Learning Network
_______________________________________________ Zope maillist - Zope@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 )