Please read for an updated status on RailsCasts:
Learn more or hide this
Nice RailsCast Ryan. Are you aware of any good write through caches for models. I'm aware of CacheMoney but it seems to be somewhat defunct for use with Rails 3.
This is a read through and write through plugin for ActiveRecord.
It can cache normal find query or has_one/belongs_to query, even find by other unique index column.
Also check find_cache gem for thread safe model caching
It is simply an ActiveRecord object caching gem using Rails.cache methods.
I'm surprised you didn't show the russian dolls technique as exposed by 37signals few months ago (http://37signals.com/svn/posts/3113-how-key-based-cache-expiration-works).
It's a great video anyway, as always. ;)
Another great video Ryan!
I would like to see something on the Russian doll technique that DHH often refers to too - perhaps with an update to the PJAX cast as well, as I think it's changed significantly since the episode that covered it.
Cool - about three weeks after this Railscast Ryan did go into the Russian doll technique, but actually did DHH's post one better. DHH outlines a manual versioning system for fragment content, since fragments can change without updating the models referenced within. As Ryan points out, that can get tricky.
In his Cache Digests Railscast, Ryan outlines how to hash and cache the full contents of a block, including the template and model contents. This eliminates the need for manual cache versioning and resolves some of the gotchas of the previous technique.
Ryan, is that a video rendering error at the end where you try to switch to "/-l" in vim? It looks like the video lags for a while.
Other than that, very nice intro to dalli!
Excellent episode Ryan. I really enjoy the fact that you're including deployment related information in your latest videos.
Do you know of a gem that is similar to dalli for redis caching (for persistence)?
Ryan, in the video you mention that the category_name method may not increase performance due to multiple reads from memcached however, couldn't this be combated through the use of memoization as you show in episode 137?
The memoization is per-request based. It's good when you want to call the same (heavy) methods many times in a request lifetime (for instance, current_user).
Just a quick note if anyone else gets 'Dalli::RingError: No server available' (or it just says false when you try to write to the cache) I had run it as:
memcached -l localhost
..and then it worked fine.
Why memcached and not redis, for example?
I have a question.
For the expression:
Rails.cache.fetch([:category, category_id, :name], expires_in: 5.minutes)
Why you didnt use :category_id here, why category_id do not need to symbolize, but category and name need to?
The cache keys need to be unique in order to fetch its value later on.
So category_id is different for each category.
Think of the array [:category, category_id, :name] as syntactic sugar for what ends up being a cache key string.
[:category, category_id, :name]
"category/3/name" # the key that caches the category's name for the category_id 3
"category/4/name" # the key that caches the category's name for the category_id 4
"category/5/name" # the key that caches the category's name for the category_id 5
and so on...
Why don't you use the include method to eager load the categories ? I think that would be a better fit than the caching you are showing. Great vid, though!
Agree with that eager loading. More on that: #22 Eager Loading (revised)
I think the intention of the screencast was to show how to use Dalli and not to focus on how to improve that example webpage.
Is it even sure that one has an perfomance plus from memcache in comparison to filecache store, if one has loads of RAM (40..45GB spare for caching) and Linux' disk cache strategy already putting files in RAM?
First sign in through GitHub to post a comment.