Ror caching

  • View

  • Download

Embed Size (px)


How caching works in Ruby on Rails.

Text of Ror caching

  • 1.Caching, in the web application world, is the art of taking a processed web page (or part of a webpage), and storing it in a temporary location. If another user requests this same webpage, then we can serve up the cached version. Loading up a cached webpage can not only save us from having to do ANY database queries (i.e. no more rountd trips to server), it can even allow us to serve up websites without touching our Ruby on Rails Server. nd all this with lightning speed

2. There's only one thing you'll need to do to start playingwith caching. Look for the following line and change it to true in your /config/environments/development.rb: config.action_controller.perform_caching = true NOTE: By default, caching is disabled for development and test, and enabled for production. 3. There are three types of caching techniques that Railsprovides by default without the use of any third party plugins. Page Caching 2) Action Caching 3) Fragment Caching 1) 4. Page caching is the FASTEST Rails cachingmechanism, so you should do it if at all possible. Where should you use page caching? If your page is the same for all users. If your page is available to the public, with noauthentication needed. 5. It cant be applied to every situation (such as pages thatneed authentication) Since the webserver is literally just serving a file from the filesystem, cache expiration is an issue that needs to be dealt with. 6. Say we have a blog page (Imagine that!) that doesn'tchange very often. The controller code for our front page might look like this: 7. As you can see, our List action queries the latest 10blog posts, which we can then display on our webpage. If we wanted to use page caching to speed things up, we could go into our blog controller and do: 8. The "caches_page" directive tells our application thatnext time the "list" action is requested, take the resulting html, and store it in a cached file. Subsequent requests to the same url will now hit this html file rather then reloading the page. As you can imagine, loading a static html page is much faster than loading and processing a interpreted programming language. Like 100 times faster! 9. However, it is very important to note that LoadingPage Cached .html files does not invoke Rails at all! What this means is that if there is any content that is dynamic from user to user on the page, or the page is secure in some fashion, then you can't use page caching. Rather you'd probably want to use action or fragment caching, 10. So, how do you enable this super-fast cache behavior?Suppose you have a controller called ProductsController and an index action that lists all the products. You could enable caching for this action like this: class ProductsController < ActionController caches_page :index def index; end end 11. The first time anyone requests products/index, Railswill generate a file called index.html. If a web server see this file, it will be served in response to the next request for products/index, without your Rails application being called. 12. By the way Where all these cached pages get stored ??? 13. By default, the page cache directory is set toRails.public_path (which is usually set to File.join(self.root, "public") that is, the public directory under your Rails applications root). The page caching mechanism will automatically add a.html extension to requests for pages that do not have an extension to make it easy for the webserver to find those pages. 14. What if we then say in our model: caches_page :show Where do you think the cachedpage would get stored when we visited "/blog/show/5" to show a specific blog post? The answer is /public/blog/show/5.html Here are a few more examples of where page caches are stored.: 15. Hey, wait a minute, notice how above the first item isthe same as the last item. Yup, page caching is going to ignore all additional parameters on your url. 16. Very interesting question, and a more interestinganswer. In order to cache your different pages, you just have to create a differently formed url. So instead of linking "/blog/list?page=2", which wouldn't work because caching ignores additional parameters, we would want to link using "/blog/list/2", but instead of 2 being stored in params[:id], we want that 2 on the end to be params[:page]. We can make this configuration change in our /config/routes.rb 17. the resulting url will be "/blog/list/2". When we clickthis link two great things will happen: Rather than storing the 2 in params[:id], which is the default, the application will store the 2 as params[:page], The page will be cached as /public/blog/list/2.html The moral of the story is; If you're going to use page caching, make sure all the parameters you require are part of the URL, not after the question mark! 18. In order to expire this page when a new product isadded you could extend the products controller like this: class ProductsController < ActionController caches_page :index def index; end def create expire_page :action => :index end end 19. action caching works like page caching except for thefact that the incoming web request does go from the web server to the Rails stack and Action Pack so that before filters can be run on it before the cache is served. This allows you to use authentication and other restrictions while still serving the result of the output from a cached copy. Clearing the cache works in the exact same way as withpage caching. 20. Lets say you only wanted authenticated users to edit orcreate a Product object, but still cache those pages: 21. You can also use :if to pass a Proc that specifies whenthe action should be cached. Also, you can use :layout => false to cache without layout so that dynamic information in the layout such as the name of the logged-in user or the number of items in the cart can be left uncached. This feature is available as of Rails 2.2. 22. Unfortunately, dynamic web applications usually buildpages with a variety of components not all of which have the same caching characteristics. In order to address such a dynamically created pagewhere different parts of the page need to be cached and expired differently Rails provides a mechanism called Fragment Caching. 23. Fragment Caching allows a fragment of view logic tobe wrapped in a cache block and served out of the cache store when the next request comes in. 24. As an example, if you wanted to show all the orders placedon your website in real time and didnt want to cache that part of the page, but did want to cache the part of the page which lists all products available, you could use this piece of code: 25. Cache sweeping is a mechanism which allows you to getaround having a ton of expire_{page,action,fragment} calls in your code. It does this by moving all the work required to expirecached content into ActionController::Caching::Sweeper class. This class is an Observer that looks for changes to an objectvia callbacks, and when a change occurs it expires the caches associated with that object in an around or after filter. 26. Query caching is a Rails feature that caches the result setreturned by each query. If Rails encounters the same query again during the current request, it will used the cached result set as opposed to running the query against the database.Query caches are created at the start of an action and destroyed at the end of that action and thus persist only for the duration of the action. 27. Rails (as of 2.1) provides different stores for the cacheddata created by action and fragment caches. Page caches are always stored on disk. 28. 1) ActiveSupport::Cache::MemoryStore: A cachestore implementation which stores everything into memory in the same process. MemoryStoreis not only able to store strings, but also arbitrary Ruby objects. MemoryStoreis not threadsafe. Use SynchronizedMemoryStore instead if you need thread-safety. 29. 2) ActiveSupport::Cache::FileStore: Cached data isstored on the disk. This is the default store and the default path for this store is: /tmp/cache. Works well for all types of environments and allows all processes running from the same application directory to access the cached content. If /tmp/cache does not exist, the default store becomes MemoryStore. 30. 3) ActiveSupport::Cache::DRbStore: Cached data isstored in a separate shared DRb process that all servers communicate with. This works for all environments and only keeps one cache around for all processes, but requires that you run and manage a separate DRb process. 31. 4) MemCached store: Works like DRbStore, but usesDangas MemCache instead. Rails uses the bundled memcached-client gem by default. This is currently the most popular cache store for production websites. Special features: Clustering and load balancing. One can specify multiple memcached servers, and MemCacheStore will load balance between all available servers. If a server goes down, then MemCacheStore will ignore it until it goes back online. Time-based expiry support. See write and the :expires_in option. Per-request in memory cache for all communication with the MemCache server(s). 32. Conditional GETs are a feature of the HTTP specificationthat provide a way for web servers to tell browsers that the response to a GET request hasnt changed since the last request and can be safely pulled from the browser cache. They work by using the HTTP_IF_NONE_MATCH andHTTP_IF_MODIFIED_SINCE headers to pass back and forth both a unique content identifier and the timestamp of when the content was last changed. If the browser makes a request where the content identifier (etag) or last modified since timestamp matches the servers version then the server only needs to send back an empty response with a not modified status. 33. Along with the built-in mechanisms outlined above, anumber of excellent plugins exist to help with finer grained control over caching. These includes1)Chris Wanstraths excellent cache_