On 5 Mar 2011, at 23:38, Wes Gamble wrote: > I need to gain a deeper understanding of how the Radiant (Rack) cache works > in order to solve a performance problem. > > PROBLEM: I've created a sidebar in my app. which traverses the entire tree of > pages using Radius tags in order to render - it basically generates a tree > view of the published page hierarchy. This is extremely slow, however, and > takes on the order of 6-10s to render. I can set up standard Radiant caching > to be some amount of time, but for each user's _first_ request, the entire > page is re-rendered (2nd - N requests are cached locally in the browser and > return just fine). > > I have read through the Radiant::Cache class, and if I understand correctly, > the SiteController.cache_timeout value is used to set the "Cache-Control" > response header's "max-age" attribute. But the behavior that this appears to > exhibit is that the first request is still a full render, and then subsequent > requests pull from the local browser cache. > > PREFERRED WORKAROUND: Obviously, I need to improve the performance of the > rendering of the sidebar, but I'd like to try and have a workaround for now. > > I wrote a cron job that requests all of the pages of the site in order to > load up the Rack cache on the server, and then allow new clients to the site > to be able to take advantage of that server side caching. But still, for any > user, that first request still takes as long as a full render. I've > verified that the Rack cache appears to be filling up on the server. > > QUESTION: Why doesn't the page get served from the server side Rack cache > when a new user request a page that has been loaded into the Rack cache? Is > it because the default Etag calculation logic in Rails involves a full > re-render of the page in order to calculate the Etag?
In testing you may not be seeing the standard public behaviour. Rack::Cache is (by default) configured to pass through any request with a Cookie: header, which means that a logged-in admin user will never hit the cache even on the published site. I've changed that recently in edge, so that the admin interface is explicitly uncached and the cookie header can be ignored. Nothing has blown up yet, but it still might. > 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. best, will
