4 ms·

There used to be many model-caching plugins for Rails, but few if any made the transition to Rails 3. The record-cache gem looks interesting and flexible, thoug

There used to be many model-caching plugins for Rails, but few if any made the transition to Rails 3. The record-cache gem looks interesting and flexible, though I haven't tried it: https://github.com/orslumen/record-cache https://github.com/orslumen/record-cache

robotmay 14y ago
I recall trying out cache-money a while back. I haven't tried out any of the current equivalents, but I may have to give them a go just to see what they can do.
- ruckusing 14y ago
  cache-money is probably the most full-featured and battle-tested (coming from Twitter and now taken over by ngmoco). However its biggest drawback is that its hard-wired to use memcached. It would be great if the actual cache backend was pluggable and we could develop a redis adapter. As it stands the memcached integration is pretty deeply intertwined into the cache-money library.
rapind 14y ago
IdentityMap is going to greatly reduce the need for model caching for the majority of sites. High traffic sites with a lot of data will still benefit from a distributed cache though. http://api.rubyonrails.org/classes/ActiveRecord/IdentityMap.html http://api.rubyonrails.org/classes/ActiveRecord/IdentityMap....
- jaylevitt 14y ago
  That would be wonderful. Unfortunately, IdentityMap was disabled by default in 3.1 because it was incomplete, and it was pulled from 4.0 for a while due to lack of development: https://github.com/rails/rails/pull/5261 https://github.com/rails/rails/pull/5261 Though there is now a company volunteering to fund completion of the feature, starting Real Soon Now: https://github.com/rails/rails/issues/5442 https://github.com/rails/rails/issues/5442 IdentityMap would, obviously, be great. Though I didn't realize it could serve as a replacement for model caching; didn't IdentityMap, like the query cache, only last for the lifetime of a request? Or could it be persisted in the Rails.cache of your choice for an arbitrary lifespan?
  - rapind 14y ago
    IdentityMap stores the model in memory for the process. Only storing for the lifetime of a request wouldn't be terribly useful. IdentityMap will be extremely useful for the majority of sites since they have very low traffic, processor, and memory demands, and therefore it's unlikely you'll have too many processes running using up their own memory containers. Though you could argue these sites really don't need additional caching anyways (they'd still respond slightly faster with IdentityMap). For high traffic sites it'll still be useful to save some trips, but you'll also want to implement and manage a distributed cache (for models, actions, fragments, etc). It's available and sort of works now. You just have to turn it on and be mindful of how associations are handled. Still a work in progress.

robotmay 14y ago

I recall trying out cache-money a while back. I haven't tried out any of the current equivalents, but I may have to give them a go just to see what they can do.

ruckusing 14y ago
cache-money is probably the most full-featured and battle-tested (coming from Twitter and now taken over by ngmoco). However its biggest drawback is that its hard-wired to use memcached. It would be great if the actual cache backend was pluggable and we could develop a redis adapter. As it stands the memcached integration is pretty deeply intertwined into the cache-money library.

rapind 14y ago

IdentityMap is going to greatly reduce the need for model caching for the majority of sites. High traffic sites with a lot of data will still benefit from a distributed cache though. http://api.rubyonrails.org/classes/ActiveRecord/IdentityMap.html http://api.rubyonrails.org/classes/ActiveRecord/IdentityMap....

jaylevitt 14y ago
That would be wonderful. Unfortunately, IdentityMap was disabled by default in 3.1 because it was incomplete, and it was pulled from 4.0 for a while due to lack of development: https://github.com/rails/rails/pull/5261 https://github.com/rails/rails/pull/5261 Though there is now a company volunteering to fund completion of the feature, starting Real Soon Now: https://github.com/rails/rails/issues/5442 https://github.com/rails/rails/issues/5442 IdentityMap would, obviously, be great. Though I didn't realize it could serve as a replacement for model caching; didn't IdentityMap, like the query cache, only last for the lifetime of a request? Or could it be persisted in the Rails.cache of your choice for an arbitrary lifespan?
- rapind 14y ago
  IdentityMap stores the model in memory for the process. Only storing for the lifetime of a request wouldn't be terribly useful. IdentityMap will be extremely useful for the majority of sites since they have very low traffic, processor, and memory demands, and therefore it's unlikely you'll have too many processes running using up their own memory containers. Though you could argue these sites really don't need additional caching anyways (they'd still respond slightly faster with IdentityMap). For high traffic sites it'll still be useful to save some trips, but you'll also want to implement and manage a distributed cache (for models, actions, fragments, etc). It's available and sort of works now. You just have to turn it on and be mindful of how associations are handled. Still a work in progress.