Thanks for your reply.
On 3/8/11 9:37 AM, William Ross wrote:
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.
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.
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.