4 ms·

Sounds... different than the caching I knew before. Problem is, I don't know Rails at all. Can anyone explaing this in non-rails speech for me? (Links are fine

by Sujan 15y ago

Sounds... different than the caching I knew before. Problem is, I don't know Rails at all. Can anyone explaing this in non-rails speech for me? (Links are fine, of course)

asmala 15y ago
The general gist of it is that you store HTML snippets (e.g. a todo, a list containing, or a project containing lists) in some quick storage medium (in this case Memcached). Each snippet is stored under and accessed by a key that uniquely identifies the version saved (object type + ID + update timestamp). When a new version is cached, the old version stays in the cache, unused, until it is eventially dropped out by Memcached. Now all you need to do is to ensure that whenever an object or its children change, you update their timestamp (the "touch" part), and if you make a changes to the code, you increment the version key for said cache piece. This way new requests will not hit old cached content.
- Sujan 15y ago
  Ok, so the first interesting part is that instead of caching the result of a database request we cache the complete rendered result. And the bigger rendered parts are just constructed by combining the smaller (also cached) parts, right? How does the application learn which version an element is at right now? Don't you have to call the database to find out?
  - asmala 15y ago
    Correct on all accounts. You will still need to query the database at least for the parent object being rendered. The time saved is shaved off from the rendering time.
  - getsat 15y ago
    If you're rendering an object, you've likely already fetched it from the DB. Rails models (by default) will have a created_at and updated_at datetime columns that are automatically set and updated for you, and you can use them for exactly what is shown in the article.
riffraff 15y ago
when you cache some html wich depends on $some_object, use a key that includes that object "version" (e.g. a timestamp). Then on first access you save the html for a key "object-x-v1" and on subsequent access you get the same html. When the object changes (v=2), so will the key ("object-x-v2), and when you access the same content again you will have a cache miss and the html will be regenerated, while the stale cache will just stay in memory until it's naturally evicted from memcache.
- Sujan 15y ago
  Got that, follow up question here: http://news.ycombinator.com/item?id=3609369 http://news.ycombinator.com/item?id=3609369

by Sujan 15y ago

Sounds... different than the caching I knew before. Problem is, I don't know Rails at all. Can anyone explaing this in non-rails speech for me? (Links are fine, of course)

asmala 15y ago

The general gist of it is that you store HTML snippets (e.g. a todo, a list containing, or a project containing lists) in some quick storage medium (in this case Memcached). Each snippet is stored under and accessed by a key that uniquely identifies the version saved (object type + ID + update timestamp). When a new version is cached, the old version stays in the cache, unused, until it is eventially dropped out by Memcached. Now all you need to do is to ensure that whenever an object or its children change, you update their timestamp (the "touch" part), and if you make a changes to the code, you increment the version key for said cache piece. This way new requests will not hit old cached content.

Sujan 15y ago
Ok, so the first interesting part is that instead of caching the result of a database request we cache the complete rendered result. And the bigger rendered parts are just constructed by combining the smaller (also cached) parts, right? How does the application learn which version an element is at right now? Don't you have to call the database to find out?
- asmala 15y ago
  Correct on all accounts. You will still need to query the database at least for the parent object being rendered. The time saved is shaved off from the rendering time.
- getsat 15y ago
  If you're rendering an object, you've likely already fetched it from the DB. Rails models (by default) will have a created_at and updated_at datetime columns that are automatically set and updated for you, and you can use them for exactly what is shown in the article.

riffraff 15y ago

when you cache some html wich depends on $some_object, use a key that includes that object "version" (e.g. a timestamp). Then on first access you save the html for a key "object-x-v1" and on subsequent access you get the same html. When the object changes (v=2), so will the key ("object-x-v2), and when you access the same content again you will have a cache miss and the html will be regenerated, while the stale cache will just stay in memory until it's naturally evicted from memcache.

Sujan 15y ago
Got that, follow up question here: http://news.ycombinator.com/item?id=3609369 http://news.ycombinator.com/item?id=3609369