Changesets can be listed by changeset number.
The Git repository is here.
- Revision:
- 373
- Log:
Initial import of Radiant 0.9.1, which is now packaged as a gem. This is an
import of the tagged 0.9.1 source checked out from GitHub, which isn't quite
the same as the gem distribution - but it doesn't seem to be available in an
archived form and the installed gem already has modifications, so this is
the closest I can get.
- Author:
- rool
- Date:
- Mon Mar 21 13:40:05 +0000 2011
- Size:
- 5416 Bytes
| 1 | Frequently Asked Questions |
| 2 | ========================== |
| 3 | |
| 4 | <p class='intro'> |
| 5 | <strong>NOTE:</strong> This is a work in progress. Please send questions, comments, or |
| 6 | suggestions to <a href="mailto:r@tomayko.com">r@tomayko.com</a>. |
| 7 | </p> |
| 8 | |
| 9 | General |
| 10 | ------- |
| 11 | |
| 12 | |
| 13 | <a class='hash' id='rails' href='#rails'>#</a> |
| 14 | |
| 15 | ### Q: Can I use Rack::Cache with Rails? |
| 16 | |
| 17 | Rack::Cache can be used with Rails 2.3 or above. Documentation and a |
| 18 | sample application is forthcoming; in the mean time, see |
| 19 | [this example of using Rack::Cache with Rails 2.3](http://snippets.aktagon.com/snippets/302-How-to-setup-and-use-Rack-Cache-with-Rails-2-3-0-RC-1). |
| 20 | |
| 21 | <a class='hash' id='why-not-squid' href='#why-not-squid'>#</a> |
| 22 | |
| 23 | ### Q: Why Rack::Cache? Why not Squid, Varnish, Perlbol, etc.? |
| 24 | |
| 25 | __Rack::Cache__ is often easier to setup as part of your existing Ruby |
| 26 | application than a separate caching system. __Rack::Cache__ runs entirely inside |
| 27 | your backend application processes - no separate / external process is required. |
| 28 | This lets __Rack::Cache__ scale down to development environments and simple |
| 29 | deployments very easily while not sacrificing the benefits of a standards-based |
| 30 | approach to caching. |
| 31 | |
| 32 | |
| 33 | <a class='hash' id='why-not-rails' href='#why-not-rails'>#</a> |
| 34 | |
| 35 | ### Q: Why Rack::Cache? Why not use Rails/Merb/FrameworkX's caching system? |
| 36 | |
| 37 | __Rack::Cache__ takes a standards-based approach to caching that provides some |
| 38 | benefits over framework-integrated systems. It uses standard HTTP headers |
| 39 | (`Expires`, `Cache-Control`, `Etag`, `Last-Modified`, etc.) to determine |
| 40 | what/when to cache. Designing applications to support these standard HTTP |
| 41 | mechanisms gives the benefit of being able to switch to a different HTTP |
| 42 | cache implementation in the future. |
| 43 | |
| 44 | In addition, using a standards-based approach to caching creates a clear |
| 45 | separation between application and caching logic. The application need only |
| 46 | specify a basic set of information about the response and all decisions |
| 47 | regarding how and when to cache is moved into the caching layer. |
| 48 | |
| 49 | |
| 50 | <a class='hash' id='scale' href='#scale'>#</a> |
| 51 | |
| 52 | ### Q: Will Rack::Cache make my app scale? |
| 53 | |
| 54 | No. Your design is the only thing that can make your app scale. |
| 55 | |
| 56 | Also, __Rack::Cache__ is not overly optimized for performance. The main goal of |
| 57 | the project is to provide a portable, easy-to-configure, and standards-based |
| 58 | caching solution for small to medium sized deployments. More sophisticated / |
| 59 | performant caching systems (e.g., [Varnish][v], [Squid][s], |
| 60 | [httpd/mod-cache][h]) may be more appropriate for large deployments with |
| 61 | crazy-land throughput requirements. |
| 62 | |
| 63 | [v]: http://varnish.projects.linpro.no/ |
| 64 | [s]: http://www.squid-cache.org/ |
| 65 | [h]: http://httpd.apache.org/docs/2.0/mod/mod_cache.html |
| 66 | |
| 67 | |
| 68 | Features |
| 69 | -------- |
| 70 | |
| 71 | |
| 72 | <a class='hash' id='validation' href='#validation'>#</a> |
| 73 | |
| 74 | ### Q: Does Rack::Cache support validation? |
| 75 | |
| 76 | Yes. Both freshness and validation-based caching is supported. A response |
| 77 | will be cached if it has a freshness lifetime (e.g., `Expires` or |
| 78 | `Cache-Control: max-age=N` headers) and/or includes a validator (e.g., |
| 79 | `Last-Modified` or `ETag` headers). When the cache hits and the response is |
| 80 | fresh, it's delivered immediately without talking to the backend application; |
| 81 | when the cache is stale, the cached response is validated using a conditional |
| 82 | GET request. |
| 83 | |
| 84 | |
| 85 | <a class='hash' id='fragments' href='#fragments'>#</a> |
| 86 | |
| 87 | ### Q: Does Rack::Cache support fragment caching? |
| 88 | |
| 89 | Not really. __Rack::Cache__ deals with entire responses and doesn't know |
| 90 | anything about how your application constructs them. |
| 91 | |
| 92 | However, something like [ESI](http://www.w3.org/TR/esi-lang) may be implemented |
| 93 | in the future (likely as a separate Rack middleware component that could be |
| 94 | situated upstream from Rack::Cache), which would allow applications to compose |
| 95 | responses based on several "fragment resources". Each fragment would have its |
| 96 | own cache policy. |
| 97 | |
| 98 | |
| 99 | <a class='hash' id='manual-purge' href='#manual-purge'>#</a> |
| 100 | |
| 101 | ### Q: How do I manually purge or expire a cached entry? |
| 102 | |
| 103 | Although planned, there is currently no mechanism for manually purging |
| 104 | an entry stored in the cache. |
| 105 | |
| 106 | Note that using an `Expires` or `Cache-Control: max-age=N` header and relying on |
| 107 | manual purge to invalidate cached entry can often be implemented more simply |
| 108 | using efficient validation based caching (`Last-Modified`, `Etag`). Many web |
| 109 | frameworks are based entirely on manual purge and do not support validation at |
| 110 | the cache level. |
| 111 | |
| 112 | |
| 113 | <a class='hash' id='efficient-validation' href='#efficient-validation'>#</a> |
| 114 | |
| 115 | ### Q: What does "Efficient Validation" mean? |
| 116 | |
| 117 | It means that your application performs only the processing necessary to |
| 118 | determine if a response is valid before sending a `304 Not Modified` in response |
| 119 | to a conditional GET request. Many applications that perform validation do so |
| 120 | only after the entire response has been generated, which provides bandwidth |
| 121 | savings but results in no CPU/IO savings. Implementing validation efficiently |
| 122 | can increase backend application throughput significantly when fronted by a |
| 123 | validating caching system (like __Rack::Cache__). |
| 124 | |
| 125 | [Here's an example Rack application](http://gist.github.com/9395) that performs |
| 126 | efficient validation. |
| 127 | |
| 128 | |
| 129 | <a class='hash' id='orly' href='#orly'>#</a> |
| 130 | |
| 131 | ### Q: Did you just make that up? |
| 132 | |
| 133 | Yes. |
| 134 | |
| 135 | |
| 136 | <a class='hash' id='https' href='#https'>#</a> |
| 137 | |
| 138 | ### Q: Can I do HTTPS with Rack::Cache? |
| 139 | |
| 140 | Sure. HTTPS is typically managed by a front-end web server so this isn't really |
| 141 | relevant to Rack::Cache. |
