5.5 KiB
Frequently Asked Questions
NOTE: This is a work in progress. Please send questions, comments, or suggestions to r@tomayko.com.
General
Q: Can I use Rack::Cache with Rails?
Rack::Cache can be used with Rails 2.3 or above. Documentation and a sample application is forthcoming; in the mean time, see this example of using Rack::Cache with Rails 2.3.
Q: Why Rack::Cache? Why not Squid, Varnish, Perlbol, etc.?
Rack::Cache is often easier to setup as part of your existing Ruby application than a separate caching system. Rack::Cache runs entirely inside your backend application processes - no separate / external process is required. This lets Rack::Cache scale down to development environments and simple deployments very easily while not sacrificing the benefits of a standards-based approach to caching.
Q: Why Rack::Cache? Why not use Rails/Merb/FrameworkX's caching system?
Rack::Cache takes a standards-based approach to caching that provides some
benefits over framework-integrated systems. It uses standard HTTP headers
(Expires, Cache-Control, Etag, Last-Modified, etc.) to determine
what/when to cache. Designing applications to support these standard HTTP
mechanisms gives the benefit of being able to switch to a different HTTP
cache implementation in the future.
In addition, using a standards-based approach to caching creates a clear separation between application and caching logic. The application need only specify a basic set of information about the response and all decisions regarding how and when to cache is moved into the caching layer.
Q: Will Rack::Cache make my app scale?
No. Your design is the only thing that can make your app scale.
Also, Rack::Cache is not overly optimized for performance. The main goal of the project is to provide a portable, easy-to-configure, and standards-based caching solution for small to medium sized deployments. More sophisticated / performant caching systems (e.g., Varnish, Squid, httpd/mod-cache) may be more appropriate for large deployments with crazy-land throughput requirements.
Features
Q: Does Rack::Cache support validation?
Yes. Both freshness and validation-based caching is supported. A response
will be cached if it has a freshness lifetime (e.g., Expires or
Cache-Control: max-age=N headers) and/or includes a validator (e.g.,
Last-Modified or ETag headers). When the cache hits and the response is
fresh, it's delivered immediately without talking to the backend application;
when the cache is stale, the cached response is validated using a conditional
GET request.
Q: Does Rack::Cache support fragment caching?
Not really. Rack::Cache deals with entire responses and doesn't know anything about how your application constructs them.
However, something like ESI may be implemented in the future (likely as a separate Rack middleware component that could be situated upstream from Rack::Cache), which would allow applications to compose responses based on several "fragment resources". Each fragment would have its own cache policy.
Q: How do I manually purge or expire a cached entry?
Although planned, there is currently no mechanism for manually purging an entry stored in the cache.
Note that using an Expires or Cache-Control: max-age=N header and relying on
manual purge to invalidate cached entry can often be implemented more simply
using efficient validation based caching (Last-Modified, Etag). Many web
frameworks are based entirely on manual purge and do not support validation at
the cache level.
Q: How do I bypass rack-cache on a per-request basis?
Set the rack-cache.force-pass variable in the rack environment to true.
Q: What does "Efficient Validation" mean?
It means that your application performs only the processing necessary to
determine if a response is valid before sending a 304 Not Modified in response
to a conditional GET request. Many applications that perform validation do so
only after the entire response has been generated, which provides bandwidth
savings but results in no CPU/IO savings. Implementing validation efficiently
can increase backend application throughput significantly when fronted by a
validating caching system (like Rack::Cache).
Here's an example Rack application that performs efficient validation.
Q: Did you just make that up?
Yes.
Q: Can I do HTTPS with Rack::Cache?
Sure. HTTPS is typically managed by a front-end web server so this isn't really relevant to Rack::Cache.