Problems of Basecamp Next caching architecture
Školení, která pořádám 
I wanted to write this post only as a comment to the article on 37signals blog but comments are closed there. Please read the article first.
This caching architecture has two problems:
- It requires four times more caching hardware. Every piece of data is saved to the cache four times (based on the example, sometimes more or less).
- It doesn't scale for writes. If data on lower levels are inserted/updated too often then the cache on high level needs to be invalidated and recreated also often. It can result in a situation where this high level cache is written only to be deleted the same second which will actually slow down the application.
Both of these problems are probably not a big deal for Basecamp Next as the writes are not so frequent and 37signals have enough money for the hardware. But they can be serious for other projects trying to use this architecture.
Comments
johno 
:
http://37signals.com/svn/posts/3113-how-key-…-expiration-works
There is another problem. If you for example change partial _todo.html.erb you have to bump version for all parent partials manually. Otherwise you end up with views mixed with new and old data. I don't know how a developer coming to a project like this finds out about all the dependencies between partials & views.
: Diskuse je zrušena z důvodu spamu.
© 2005-2024 