3 ms·

I use most of these methods for caching. I have my own little methods for making cache keys. I use Rails.cache all over the place. I have a couple sweepers. Wha

I use most of these methods for caching. I have my own little methods for making cache keys. I use Rails.cache all over the place. I have a couple sweepers. What I really struggle is testing this stuff. You really can't do it anywhere other than an integration test, and they're ugly. I mostly just test the sweepers. Anyone have any nice solutions for testing caching, or think its unnecessary?

joevandyk 15y ago
I would try to remove as much caching as possible. It is complicated and hard to test.
- johnkchow 15y ago
  I've never had a production Rails project, but do you have any anecdotes or numbers to back up your statement? From initial glance, it looks like the win in processing speed outweights the complexity. So then you're implying that this win isn't required. I'm assuming that scaling out is cheaper than the complexity cost of implementing/maintaining such a caching solution?
- nfm 15y ago
  I haven't had a lot of experience with caching, and I agree with your comment above about database views, but wouldn't the complications be mitigated by using the approach DHH detailed recently? http://37signals.com/svn/posts/3113-how-key-based-cache-expiration-works http://37signals.com/svn/posts/3113-how-key-based-cache-expi... That is, incorporating `updated_at` into the cache key, and using `touch: true` on your AR relations to make sure that caches of affected parent objects get expired too? Are there other complications I may not have run into yet?
  - joevandyk 15y ago
    Imagine you have User has_many Comments. When someone's username is updated, you might need to update all the user's cached html comment fragments to include the new username. However, ActiveRecord doesn't support touch on has_many relations. (It probably shouldn't, as updating the username would mean updating/touching thousands (or more) comment rows). Also, if you have to update the database outside of ActiveRecord for any reason, you could be screwed - the cache would become out of sync with the database.
    - nfm 15y ago
      Cheers, a helpful and extremely likely case!

joevandyk 15y ago

I would try to remove as much caching as possible. It is complicated and hard to test.

johnkchow 15y ago
I've never had a production Rails project, but do you have any anecdotes or numbers to back up your statement? From initial glance, it looks like the win in processing speed outweights the complexity. So then you're implying that this win isn't required. I'm assuming that scaling out is cheaper than the complexity cost of implementing/maintaining such a caching solution?
nfm 15y ago
I haven't had a lot of experience with caching, and I agree with your comment above about database views, but wouldn't the complications be mitigated by using the approach DHH detailed recently? http://37signals.com/svn/posts/3113-how-key-based-cache-expiration-works http://37signals.com/svn/posts/3113-how-key-based-cache-expi... That is, incorporating `updated_at` into the cache key, and using `touch: true` on your AR relations to make sure that caches of affected parent objects get expired too? Are there other complications I may not have run into yet?
- joevandyk 15y ago
  Imagine you have User has_many Comments. When someone's username is updated, you might need to update all the user's cached html comment fragments to include the new username. However, ActiveRecord doesn't support touch on has_many relations. (It probably shouldn't, as updating the username would mean updating/touching thousands (or more) comment rows). Also, if you have to update the database outside of ActiveRecord for any reason, you could be screwed - the cache would become out of sync with the database.
  - nfm 15y ago
    Cheers, a helpful and extremely likely case!