On 8 Mar 2011, at 16:18, Wes Gamble wrote: > William, > > 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).
A successful Rack::Cache hit is a big win. A cache hit should reduce your response time to little more than webserver delays and in a relatively static radiant site with a long cache lifetime that's what you get. That's really the situation for which radiant is ideal. As soon as you move away from a simple publishing scenario it gets more strained, and if you introduce any degree of personalisation or responsiveness you're thrown back on the basic rendering machinery. As you've found, it's not optimised for speed. That's the price of flexibility: there is no determinate way to work out which pages are invalidated by changes to a particular object, so we can't render at save and there is no shortcut to an etag or even a last-modified date. We just have to render the page. > Agreed on making Radius less slow - if I have time, I will look at it. The good news there is that Radius development can proceed independently of radiant's release programme. The bad news is that the only real speedup will come from rewriting the ragel machine definition to emit C instead. best, will
