5 ms·

It's out of fashion today, but N+1 queries are also useful (and preferred) if you're doing russian doll caching which were popular at Basecamp. It lets you onl

It's out of fashion today, but N+1 queries are also useful (and preferred) if you're doing russian doll caching which were popular at Basecamp. It lets you only query and cache the resources that have changed, not the whole dataset: https://blog.appsignal.com/2018/04/03/russian-doll-caching-in-rails.html https://blog.appsignal.com/2018/04/03/russian-doll-caching-i...

hinkley 4y ago
I've never set out to implement russian doll caching, so I could be talking out of my butt, but I've worked on several projects that arrived at RDC by just throwing more and more caches at everything, and the fatal flaw there is that nobody ever goes back and determines if Cache C is undermining the effectiveness of Cache A, or if Cache C obsoletes Cache A, and should have been presented as a replacement instead of a supplement. Each cache is another failure point, and if you go down the caching rabbit hole then the appropriateness of each cache is a question that is never definitively answered. The answer changes with new features, every time your cluster grows, or shrinks, or upgrades to new instance types. It becomes a tax on your project that is either paid as you go or all at once when your complacency results in a production issue, or magnifies one.
- kawsper 4y ago
  Basecamp/37signals also wrote about their use of the strategy here: https://signalvnoise.com/posts/3690-the-performance-impact-of-russian-doll-caching https://signalvnoise.com/posts/3690-the-performance-impact-o... I only know of them to be using it extensively, it's from 2013, so maybe things have changed :)
JamesSwift 4y ago
People still use russian doll caching, but its a bit of a pain honestly due to having to make sure to call `touch` in all the appropriate places, which is surprisingly a lot of places. Its very easy to forget to do so and end up with stale caches.

hinkley 4y ago

I've never set out to implement russian doll caching, so I could be talking out of my butt, but I've worked on several projects that arrived at RDC by just throwing more and more caches at everything, and the fatal flaw there is that nobody ever goes back and determines if Cache C is undermining the effectiveness of Cache A, or if Cache C obsoletes Cache A, and should have been presented as a replacement instead of a supplement. Each cache is another failure point, and if you go down the caching rabbit hole then the appropriateness of each cache is a question that is never definitively answered. The answer changes with new features, every time your cluster grows, or shrinks, or upgrades to new instance types. It becomes a tax on your project that is either paid as you go or all at once when your complacency results in a production issue, or magnifies one.

kawsper 4y ago
Basecamp/37signals also wrote about their use of the strategy here: https://signalvnoise.com/posts/3690-the-performance-impact-of-russian-doll-caching https://signalvnoise.com/posts/3690-the-performance-impact-o... I only know of them to be using it extensively, it's from 2013, so maybe things have changed :)

JamesSwift 4y ago

People still use russian doll caching, but its a bit of a pain honestly due to having to make sure to call `touch` in all the appropriate places, which is surprisingly a lot of places. Its very easy to forget to do so and end up with stale caches.