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
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
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?
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?
I am looking at using this:
https://github.com/mokisystems/radiant-fragment-cacher to cache the
sidebar when it’s created.