farcry cms

FarCry already has various mechanisms for caching content. These make it easy to do things like cache some parts of a page and not others, have different timeouts for each, automatically expire caches if content changes, and so on. This is possible because the cache is managed in memory on the same server where the data is edited by administrators, and the HTML is generated by FarCry.

Where FarCry caching is a sophisticated and granular caching solution, a reverse proxy (RP) is the "big hammer" solution. One for complex and highly dynamic content, the other for overwhelming traffic and mostly static content.

Thus controlling RP caching is a different beast. It is simple and unwieldy, because it needs to perform well under high load. It is possible to create complicated caching strategies with an RP like Varnish, but we have gone with a simpler approach:

• cache based on the s-maxage header in backend responses
  
• clear a site's entire cache on GET /varnishpurge from an authorised IP address

This moves control of which pages get cached and for how long back to FarCry. But this is still fundamentally different to FarCry's internal caching options:

• page caching strategy VS fragment caching strategy
  
• cache refreshed on timeout VS refresh on timeout, or content change
  
• cache by URL (and to a lesser extent cookies and user agent) VS cache by URL, form, user role, custom variables

Because of this we decided that it didn't make sense to try to extrapolate the RP cache timeout based on a projects existing config. Instead we added support for a new webskin decorator: @@proxyCacheTimeout [https://farcry.jira.com/wiki/display/FCDEV60/Cache+Headers]. This means developers will need to consciously decide which pages to cache and for how long.