RE: [Zope-dev] How to make Zope fail nicely under high load?
Richard Jones wrote:
On Thursday 12 February 2004 01:23, Casey Duncan wrote:
What kinds of requests are these? Do they all require a dynamic output? If not, then you should put better caching in front of Zope,
or at a minimum tweak you caching headers so that some could be served as 304s for instance.
If they are all dynamic, how dynamic? How different is the page for one session than another? If much of the page is the same then you might benefit from an ESI approach where you cache parts of pages and assemble them in the cache, serving only small pieces from Zope.
I'm a bit surprised that you have not (from what I can see), used the most common Zope speedup (and often the cheapest overall): Buy more hardware and use ZEO.
I was going to suggest these things too. And a bunch of other stuff. A while ago, I wrote a page about making Zope go faster - it might help.
Okay, I'd better explain our situation in more detail, then. Richard, Casey, thanks. Except for using ZEO, we're already doing everything Richard and you mentions. Zope only serves pages (no images etc) that are dynamic, the object cache is set at 20,000 objects with only 2 threads (otherwise we got too much deactivation of objects), and we also use the RAM Cache Manager for static bits of dynamic pages. We could probably have used it more, but since it can't cache persistent objects, it's a bit of a pain sometimes. The point is, our template is very dynamic, and our application (a BBS) is very dynamic as well. We have done one round of optimization (basically making things as cacheable as possible) and after testing the scalability now we're going to do another round of optimization, tweaking the algorithm and removing as many ZCatalog searches as possible. One of the optimization we're thinking of is storing results of ZCatalog searches (e.g., number of replies to postings) in volatile variables so we don't have to run the catalog search at all. We'd like to use memory space shared between threads for this. Using ZEO would require us to store this in the ZODB. I'm sure we can make the application run faster, but we'd like to support 500-1000 simultaneous users whereas now we can only support 20-25! I don't know if we can scale it enough just by tweaking the application. Another option is to scrap Zope for the BBS part and use one of the fully featured, and optimized, BBS applications for PHP. That would definitely be a safer choice, but would require extra application integration time (user database, searching). Regards, -- Bjorn
Bjorn Stabell wrote:
Okay, I'd better explain our situation in more detail, then.
The point is, our template is very dynamic, and our application (a BBS) is very dynamic as well. We have done one round of optimization (basically making things as cacheable as possible) and after testing the scalability now we're going to do another round of optimization, tweaking the algorithm and removing as many ZCatalog searches as possible.
If you are optimising for speed, there is nothing wrong with only making 1 catalog query, and then format the page from that. If possible. That is basically what php base boards do anyway. Also if the page is that dynamic, and you need that much speed, maybe you shouldn't use zpt very much. You could generate the most critical pages from pure Python. That would allow for a whole different bag tricks, but still be nicer than php. Like caching a generated view and then replacing it vith a python generated board view. def re_cache(self) self.layout_cache = self.board_template(self, self.REQUEST) def index_html(self): board_view = self.generate_board_view() return self.layout_cache.replace('%%board_view%%', board_view) regards Max M
On Thursday 12 February 2004 00:57, you wrote:
One of the optimization we're thinking of is storing results of ZCatalog searches (e.g., number of replies to postings) in volatile variables so we don't have to run the catalog search at all. We'd like to use memory space shared between threads for this. Using ZEO would require us to store this in the ZODB.
Storing that in ZODB would be a bad idea. Theres no reason to think that this cache would be faster than ZCatalog. I dont see why you would be *required* to store in ZODB... just dont share your cache between publisher threads on different Zope instances. (my apologies if this is obvious) -- Toby Dickenson
participants (3)
-
Bjorn Stabell -
Max M -
Toby Dickenson