Martijn Faassen wrote:
Evan Simpson wrote:
Rob Page wrote:
Over time you learn that dtBigExpensivePage is, in fact, expensive to render. Sooo, you might create a ZCache object in Folder foo called dtBigExpensivePage and move the DTML Method dtBigExpensivePage into
the
ZCache (a folderish thing) object dtBigExpensivePage.
As a result, you'd be able to access http://machine.com/foo/dtBigExpensivePage and get the cached rendering and maybe access:
http://machine.com/foo/dtBigExpensivePage/dtBigExpensivePage to get the uncached rendition.
Of course, this lets you, over time and selectively build cached renditions of expensive objects...
That's basically what I was thinking, yes.
Sounds like a good way to cache XML Documents renderings too! This sounds quite elegant as it'd work with most objects out of the box. There might be some interactions with acquisition that could muddle things, though..
I agree. Right now I have to render everything to a dtml document and serve that up instead of the actual xml document. That seems to work pretty well, but a more straightforward way to cache things is certainly needed, especially if it lets me cache the results of individual objects that can then be included in other (non-cached) objects. As I understand it, this scheme would pretty much create a cached copy of the rendered object which would itself live in the ZODB. It seems like there is still a performance penalty with keeping the cached item in the ZODB though (even when the object is in-memory), for instance I can serve 30-40 concurrent static DTML Documents from ZServer on my machine, but when I render the same material to disk and serve from apache the performance leaps ahead. Maybe a top-level cache should bypass the ZODB altogether if it can, maybe an in-memory cache that sits in front of Zope which ZServer hits first to try and return pages from. If something moves into the ZCache, then it moves into the top-level cache, and requests for it are simply intercepted before zope gets hit. This wouldn't work for pages that render based on specific authorizations, etc... but those requests would just fall back to piecing together a page from pre-rendered parts in the secondary (in ZODB) ZCache. Or maybe I'm misunderstanding this altogether. Jason