RE: [Zope-dev] Caching
"<!--#cache--> <!--#foo bar--> <!--#/cache-->", where foo bar can be an SQL call..
SQL Methods have a tunable parameter for cacheing results on the Advanced tab. For other kinds of objects the ZODB takes pains to keep frequently used objects in memory. Objects are retired after they've been untouched for some time. Check out: Control_Panel -> Database Management -> Cache Paramters --Rob
Rob Page wrote:
"<!--#cache--> <!--#foo bar--> <!--#/cache-->", where foo bar can be an SQL call..
SQL Methods have a tunable parameter for cacheing results on the Advanced tab.
For other kinds of objects the ZODB takes pains to keep frequently used objects in memory. Objects are retired after they've been untouched for some time.
How about *result* cacheing for non-SQL objects? On numerous occasions I have wished that I could tell Zope to cache the output of a document or method across requests. Then I would want to clear the cached value either after some elapsed time, or on-demand as the underlying data changed. Even better would be the ability to write a method which decides on a per-request basis when to clear the cache. I'm tempted to try using PythonMethod globals as cache, but I'm a little worried about concurrency issues. Something like: global cache now = ZopeTime() if cache is not None: cached_on, txt = cache if now >= cached_on + 0.5: # every half-day cache = None if cache is None: txt = myDTMLDoc(_, REQUEST) cache = (now, txt) return txt The worst that should happen is wasted concurrent attempts to refresh the cache, right?
On Sun, 12 Sep 1999, Rob Page wrote:
"<!--#cache--> <!--#foo bar--> <!--#/cache-->", where foo bar can be an SQL call..
SQL Methods have a tunable parameter for cacheing results on the Advanced tab.
For other kinds of objects the ZODB takes pains to keep frequently used objects in memory. Objects are retired after they've been untouched for some time.
Check out: Control_Panel -> Database Management -> Cache Paramters
BTW, I know that Apache has quite extensive caching built into it. I'm not sure what the API is like for this cache stuff, but it would be really cool if you could give it a list of pages to cache more aggresively on your site ie. the heavily hit dynamic homepage could expire every 5 minutes, etc. Then again, the caching might be better handled elesewhere in the foodchain.. Maybe in conjunction with mod_pcgi this could work well. BTW, is anyone using mod_pcgi at all? ------- Jordan B. Baker -- jbb@spyderlab.com weaving the web @ http://www.spyderlab.com
Consider this scenario: You want to cache a high-demand page for one minute or until new content is added, whichever is *longer* (updates are frequent, and would defeat the cache). You create a ZCache object such that it will be published at the desired URL, and you place the DTML Document which defines the page inside of it (it can hold exactly one object). You set the ZCache's minimum_time property to 60 seconds and leave maximum_time blank. In the object which adds new content, you call the manage_reset method of the ZCache object. Elsewhere in your site, you have an expensive, frequently called method whose rendering should only change if one of its properties or its content is edited. You put it in a ZCache object, and also edit the ZCache object's default manage_cacheTest method so that it checks and stores the modification timestamp of the cached object. A ZCache would act as a proxy for its contained object, storing the last-rendered text as a volatile value. Simple cache rules could be set via properties, while more complicated rules could be implemented with manage_reset, manage_resetForced, and manage_cacheTest. manage_resetForced would override rules, while manage_reset would respect them. manage_cacheTest would have easy access to volatile storage. Thoughts?
participants (3)
-
Evan Simpson -
Jordan B. Baker -
Rob Page