Re: Zope vs Plone: performance issues!
Subject: Re: Zope vs Plone: performance issues! Alexander Limi wrote:
On Wed, 25 Jan 2006 00:11:04 -0800, Dario Lopez-Kästen <dario-tTo+xxYJ+kmv1QaEFLkzfg@public.gmane.org> wrote:
Start by checking the ZODB cache numbers in the zope-conf file (too start simple). IIRC, the default is 5000 objects. Increase that to, say 50.000 or so (you mention that you have a busy site).
Sorry, but this is not good advice. 5000 objects in the cache is normally plenty, and you should look into caching the front-end before you even consider this. 50K objects in the cache will eat *a lot* of memory, and most likely cause swapping.
Cache properly with Apache or Squid in front first, then investigate the more complex settings.
Does this apply for personanlsied content as well? Remember, his site is an intranet. We at least, have had good results by increasing the internal ZODB caching. I fail to see how squid could help us with a site that is mostly non-static. It would be nicer of course if we could use some other kind of caching, so I am always open to suggestions :-) /dario -- -- ------------------------------------------------------------------- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech. Lyrics applied to programming & application design: "emancipate yourself from mental slavery" - redemption song, b. marley
On 25 Jan 2006, at 11:36, Dario Lopez-Kästen wrote:
Start by checking the ZODB cache numbers in the zope-conf file (too start simple). IIRC, the default is 5000 objects. Increase that to, say 50.000 or so (you mention that you have a busy site). Sorry, but this is not good advice. 5000 objects in the cache is normally plenty, and you should look into caching the front-end before you even consider this. 50K objects in the cache will eat *a lot* of memory, and most likely cause swapping. Cache properly with Apache or Squid in front first, then investigate the more complex settings.
Does this apply for personanlsied content as well? Remember, his site is an intranet.
We at least, have had good results by increasing the internal ZODB caching. I fail to see how squid could help us with a site that is mostly non-static. It would be nicer of course if we could use some other kind of caching, so I am always open to suggestions :-)
Increasing the ZODB cache is a good thing, you just need to keep RAM usage in check. The bigger the cache, the more RAM you use. Swapping would quickly annihilate any advantages you gain by having the cache. You should also look at increasing the ZEO cache size if you use ZEO. This can be done in zope.conf as well. The ZEO cache is a disk cache. jens
On Wed, Jan 25, 2006 at 11:47:21AM +0000, Jens Vagelpohl wrote:
You should also look at increasing the ZEO cache size if you use ZEO. This can be done in zope.conf as well. The ZEO cache is a disk cache.
+9 on that. This is the cache-size setting *within* the <zeoclient> section. Fetching an object from ZEO over the network can be MUCH slower than fetching the object from a local FileStorage, depending on the network of course, but even on localhost ZEO has some overhead that can be significant -- especially for loading Images and Files. If instead the object is in the ZEO cache, no network request is made and the speed is basically equivalent to FileStorage. So, if you have a lot of objects that are read more often than they are written, a big ZEO client cache can be very helpful. It's still 20 MB by default IIRC, which is probably too small for most "real" storage sizes. The clue that you need to bump it up is in your event.log. See how often there are lines like: 2006-01-25T10:30:59 INFO(0) ZEC:1-None-0 flipping cache files. new current = 0 AFAIK, that means you've used up half of the specified cache size since the previous time such a message appeared. There's no hard fast rule about how often you should want to see a cache flip. If you see this once a week, you're fine but you could get away with a smaller cache if you care about the wasted disk space. If you see it every five minutes, you have a too small disk cache. Somewhere in between is good ;-) I prefer to err on the side of making it huge, and stop worrying about it. -- Paul Winkler http://www.slinkp.com
participants (3)
-
Dario Lopez-Kästen -
Jens Vagelpohl -
Paul Winkler