diff options
Diffstat (limited to 'railties/guides/source/caching_with_rails.textile')
| -rw-r--r-- | railties/guides/source/caching_with_rails.textile | 36 |
1 files changed, 12 insertions, 24 deletions
diff --git a/railties/guides/source/caching_with_rails.textile b/railties/guides/source/caching_with_rails.textile index 91827fd493..4273d0dd64 100644 --- a/railties/guides/source/caching_with_rails.textile +++ b/railties/guides/source/caching_with_rails.textile @@ -15,7 +15,7 @@ h3. Basic Caching This is an introduction to the three types of caching techniques that Rails provides by default without the use of any third party plugins. -To start playing with testing you'll want to ensure that +config.action_controller.perform_caching+ is set to +true+ if you're running in development mode. This flag is normally set in the corresponding +config/environments/*.rb+ and caching is disabled by default for development and test, and enabled for production. +To start playing with caching you'll want to ensure that +config.action_controller.perform_caching+ is set to +true+, if you're running in development mode. This flag is normally set in the corresponding +config/environments/*.rb+ and caching is disabled by default for development and test, and enabled for production. <ruby> config.action_controller.perform_caching = true @@ -23,9 +23,9 @@ config.action_controller.perform_caching = true h4. Page Caching -Page caching is a Rails mechanism which allows the request for a generated page to be fulfilled by the webserver (i.e. apache or nginx), without ever having to go through the Rails stack at all. Obviously, this is super-fast. Unfortunately, it can't be applied to every situation (such as pages that need authentication) and since the webserver is literally just serving a file from the filesystem, cache expiration is an issue that needs to be dealt with. +Page caching is a Rails mechanism which allows the request for a generated page to be fulfilled by the webserver (i.e. Apache or nginx), without ever having to go through the Rails stack at all. Obviously, this is super-fast. Unfortunately, it can't be applied to every situation (such as pages that need authentication) and since the webserver is literally just serving a file from the filesystem, cache expiration is an issue that needs to be dealt with. -So, how do you enable this super-fast cache behavior? Simple, let's say you have a controller called +ProductsController+ and an +index+ action that lists all the products +To enable page caching, you need to use the +caches_page+ method. <ruby> class ProductsController < ActionController @@ -35,11 +35,10 @@ class ProductsController < ActionController def index @products = Products.all end - end </ruby> -The first time anyone requests +/products+, Rails will generate a file called +products.html+ and the webserver will then look for that file before it passes the next request for +/products+ to your Rails application. +Let's say you have a controller called +ProductsController+ and an +index+ action that lists all the products. The first time anyone requests +/products+, Rails will generate a file called +products.html+ and the webserver will then look for that file before it passes the next request for +/products+ to your Rails application. By default, the page cache directory is set to +Rails.public_path+ (which is usually set to the +public+ folder) and this can be configured by changing the configuration setting +config.action_controller.page_cache_directory+. Changing the default from +public+ helps avoid naming conflicts, since you may want to put other static html in +public+, but changing this will require web server reconfiguration to let the web server know where to serve the cached files from. @@ -104,7 +103,7 @@ INFO: Action caching runs in an after filter. Thus, invalid requests won't gener h4. Fragment Caching -Life would be perfect if we could get away with caching the entire contents of a page or action and serving it out to the world. Unfortunately, dynamic web applications usually build pages with a variety of components not all of which have the same caching characteristics. In order to address such a dynamically created page where different parts of the page need to be cached and expired differently Rails provides a mechanism called Fragment Caching. +Life would be perfect if we could get away with caching the entire contents of a page or action and serving it out to the world. Unfortunately, dynamic web applications usually build pages with a variety of components not all of which have the same caching characteristics. In order to address such a dynamically created page where different parts of the page need to be cached and expired differently, Rails provides a mechanism called Fragment Caching. Fragment Caching allows a fragment of view logic to be wrapped in a cache block and served out of the cache store when the next request comes in. @@ -112,7 +111,7 @@ As an example, if you wanted to show all the orders placed on your website in re <ruby> <% Order.find_recent.each do |o| %> - <%= o.buyer.name %> bought <% o.product.name %> + <%= o.buyer.name %> bought <%= o.product.name %> <% end %> <% cache do %> @@ -162,17 +161,17 @@ class ProductSweeper < ActionController::Caching::Sweeper # If our sweeper detects that a Product was created call this def after_create(product) - expire_cache_for(product) + expire_cache_for(product) end # If our sweeper detects that a Product was updated call this def after_update(product) - expire_cache_for(product) + expire_cache_for(product) end # If our sweeper detects that a Product was deleted call this def after_destroy(product) - expire_cache_for(product) + expire_cache_for(product) end private @@ -189,7 +188,7 @@ end You may notice that the actual product gets passed to the sweeper, so if we were caching the edit action for each product, we could add an expire method which specifies the page we want to expire: <ruby> - expire_action(:controller => 'products', :action => 'edit', :id => product) +expire_action(:controller => 'products', :action => 'edit', :id => product.id) </ruby> Then we add it to our controller to tell it to call the sweeper when certain actions are called. So, if we wanted to expire the cached content for the list and edit actions when the create action was called, we could do the following: @@ -345,7 +344,7 @@ ActionController::Base.cache_store = MyCacheStore.new h4. Cache Keys -The keys used in a cache can be any object that responds to either +:cache_key+ or to +:to_param+. You can implement the +:cache_key+ method on your classes if you need to generate custom keys. ActiveRecord will generate keys based on the class name and record id. +The keys used in a cache can be any object that responds to either +:cache_key+ or to +:to_param+. You can implement the +:cache_key+ method on your classes if you need to generate custom keys. Active Record will generate keys based on the class name and record id. You can use Hashes and Arrays of values as cache keys. @@ -382,6 +381,7 @@ class ProductsController < ApplicationController # anything. The default render checks for this using the parameters # used in the previous call to stale? and will automatically send a # :not_modified. So that's it, you're done. + end end </ruby> @@ -403,15 +403,3 @@ end h3. Further reading * "Scaling Rails Screencasts":http://railslab.newrelic.com/scaling-rails - - -h3. Changelog - -* Feb 17, 2011: Document 3.0.0 changes to ActiveSupport::Cache -* May 02, 2009: Formatting cleanups -* April 26, 2009: Clean up typos in submitted patch -* April 1, 2009: Made a bunch of small fixes -* February 22, 2009: Beefed up the section on cache_stores -* December 27, 2008: Typo fixes -* November 23, 2008: Incremental updates with various suggested changes and formatting cleanup -* September 15, 2008: Initial version by Aditya Chadha |