Front-Line Cache Configuration | alo's web site

Front-Line Cache Configuration

This post will introduce how to configure Front-Line Cache, a new form of data caching offered in Cherokee 1.2.98.

Front-Line Cache provides the functionality of a regular Proxy-cache server, with a very big difference: it is not an independent second server which all the Web server traffic must also go through. Instead, Front-Line Cache is built into the Cherokee Web Server. This new architecture brings the same benefits as an independent Proxy-cache server, while it does not add any latency to the response (due to the network based communication between two different pieces of software), nor it use competing system resources (due to the duplication of resources between Web and Proxy servers: memory, poll of descriptors, sockets, etc.).

To try Front-Line Cache install Cherokee 1.2.98 (or greater). As usual, new packages for Ubuntu and MacOS X are made available a few minutes after the source tarball release.

How to Enable Front-Line Cache

Enabling Front-Line Cache is a pretty straightforward process that takes literally, a minute. The whole configuration process is performed via Cherokee-admin, so you don’t have to deal with complexity of plain ol’ configuration files.

There are two ways of enabling Front-Line Cache on a virtual server:

Front-Line Cache Wizard

1. Wizard: A wizard is provided to auto-configure the caching of a selected virtual server. This method will add a rule or two to your virtual host to enable the caching support and its administrative interface (accessed by standard PURGE requests).

   It is a fairly straightforward process:

   • Click vServer on Top menu
   • Select the Virtual Server
   • Behavior tab
   • Click Rule Management
   • Click on the "+" button to add new rules
   • Select the Tasks section
   • Select the Content Caching wizard

   The wizard provides two configuration options that cover most of the use cases of the cache mechanism:

   • Store Cacheable Dynamic Responses: This option will cache all the responses that are explicitly subject to be stored in a cache. That is, responses including the Cache-Control or Expires headers. If you are trying to speeding up a Web application this is the way to go.
   • Store Encoded Responses from Static files: Cherokee will store a copy of the encoded (GZip or Deflate) version of static files, so when they are subsequently requested, the server does not need to compress it again.

   Additionally, the wizard allows you to configure an administrative interface from which entries in the cache can be purged remotely. We have implemented a PURGE interface, for the sake of consistency with other Proxy-cache projects.

2. Manual: It's also possible to enable the Cache capabilities of Cherokee in finer-grain, per-rule way.

   Starting in Cherokee 1.2.98 a new "Caching" tab has been incorporated to the Rule management interface. It allows you to define whether or not the content may be cached, and which responses are subject to this process.

   The Responses to Cache option is specially relevant in the section. It defines if the explicitly cacheable responses are the only responses that can be cached, or if the server should apply a much more aggressive caching policy by storing all the responses except the ones that are explicitly forbidden to cache.

   There are a few reasons why a response is considered to be non-cacheable:

   • The object was requested over HTTPS
   • The object required authentication
   • The headers of the response forbids its caching. Either of the following header would forbid caching:
     • Control-Cache, with a "no-cache", "no-store", "must-revalidate" or "proxy-revalidate" properties
     • Expires: with a time in the past
     • Pragma: with a "no-cache" value
   • The headers of the response sets a cookie for the client (Cherokee allows you to ignore certain cookies, so they are not taken into account while evaluating the cacheability of a response. This provides an override where content where cookie(s) exist can be made cacheable)

How to Test That Front-Line Cache is Working

After applying the cache configuration changes to Cherokee you should confirm that cache is indeed working as expected. We do this by using curl, a common Linux tool to look at the HTTP Headers.

curl -v http://www.yourdomain.com/ | head -40

The presence of an X-Cache value indicates that Cherokee's Front-Line Cache is active. The first request for a URL should return: X-Cache: MISS from www.yourdomain.com. Subsequent requests where Cache is functioning should return: X-Cache: HIT from www.yourdomain.com

Further Debugging

The most common reason why backend content will fail to be cacheable is due to the presence of cookies.

Again, utilizing curl to look at the underlying HTTP data we can determine the presence of cookies that are impacting cacheability:

curl -v http://www.yourdomain.com/ | head -40

If you see a "Set-Cookie: value, expires=" type entry via curl then that data is unable to be cached. You have two choices when this occurs, either stop the backend server from sending cookies which might be complicated or even out of your control or override the values via Cherokees Front-Line Cache features.

To make a cookie present request cacheable within Cherokee we have provided a configuration option under caching, called Disregarded Cookies. This option allows Cherokee to ignore some or all cookies depending on your configuration preferences.

• Click vServer on Top menu
• Select the Virtual Server
• Behavior tab
• Click the Behavior Rule where cache is enabled
• Scroll down the Content Expiration screen until you see Disregarded Cookies

Disregarded cookies entries are defined by regular expressions.

In the extreme case you wanted to disregard all cookies and make a document cacheable is to provide a New Regular Expression: Regular Expression: .*

WARNING: Setting Cherokee to ignore cookies in this manner could expose personal data where cookies are used to relate data to a user or to show a user's personal information, log-in area, etc. Use with caution on non-personalized pages only.