Thanks for your reply.

On 3/8/11 9:37 AM, William Ross wrote:
On 5 Mar 2011, at 23:38, Wes Gamble wrote:
QUESTION: Is the current caching scheme in Radiant (Rack) completely dependent on client-side caching, implying that a given user _must_ do a full render before any caching benefits are realized?

No. The default cache timeout is only five minutes, though. I normally increase that to at least a week. During the timeout interval you should only be rendering the page once.

I have been wondering about putting a 'cacheable?' flag on snippets and perhaps even rendering them on save if that flag is set. It feels a bit overcomplicated, though. The time would probably be better spent making radius less slow in the first place.

Even that one time is too much because it results in a ~10s page load. In the meantime, I have implemented the fragment cache extension (which although it was last updated for Radiant 0.8, works fine in 0.9.1) to cache these slow-rendering snippets.

I think you've answered my question, in that it appears that Rack::Cache is only "pre-configured" to handle freshness based client side caching, and although you _could_ use it for server side caching, Radiant isn't set up out of the box to do that. I am still looking into it. The default Etag behavior implemented by Rails and Rack::Cache seems to only save you response transmission time on a cache hit, which doesn't seem like a particularly big win (if I understand correctly).

Agreed on making Radius less slow - if I have time, I will look at it.


Reply via email to