Comments

• Carsten 21 Jul 06:19

  This was a great talk, the concept of generations is so elegant. Thanks Tobi!

• Adam Wisniewski 21 Jul 06:50

  One of the best presentations at RubyFringe. Thanks for the slides.

• Paul Doerwald 21 Jul 18:26

  I really enjoyed the talk as well. I’m intrigued by the “tag-based expiry”, but I wasn’t able to Google anything up about it. Do you have any idea when this will be available in memcached?

• Dan Grigsby 21 Jul 18:37

  Great presentation, Tobi. Good to see you and meet the other Shopifians and Fiona.

• Ryan Lowe 21 Jul 19:23

  Looking forward to the video of this presentation!

• Tobias Lütke 22 Jul 04:47

  The tag based expiry is pretty much vapor ware at the moment. Its generally agreed upon that it will come to memcached but no one has come up with the right implementation yet. There are some projects which added it but the problem with memcached is that every client command has to have a O(1) runtime which is incredibly tricky with tags.

  I have a pretty brain-dead implementation that simply expires the tags with a for loop O(N) which I use for prototyping and I have an idea of how to reach O(1) using a method very similar to the generations feature I described in my talk.

  I hope someone with more experience in data structures can step up to the task in the future. It would truly take mem-cache-dee to the next level.

• Rowan 22 Jul 11:44

  Thanks Tobi for putting this up ! This was definitely my favourite tech talk of the weekend. Drop me a line..

• Pete Forde 22 Jul 18:54

  I would describe it as me hoping you’d come and talk about memcached… but the end result was the same: celebrity status for your children.

• Morten 27 Jul 07:37

  Nice Toby. Really nice.

  I have a question to the your approach. Let’s say you have a blog consisting of posts with comments and that rendering a comment is pretty CPU intensive. A comment never changes.

  I’m considering these approaches (post has the “generation” attribute which gets updated once a comment is made):

  1. Fragment cache each comment

  2. Build a single post-id-comments cache entry and append newly rendered comments to that.

  I’m intrigued by option 2. Do you have any experience to share in regards to this approach?

  Thanks.

• Roob 27 Jul 10:33

  hi tobi,

  thanks for uploading your presentation! which console font are you using in it?

  thanks rob

• Matthew Gaddis 28 Jul 13:29

  I’m not sure if this idea is inline with “tag based expiry” but its an O(1) solution to managing fragments that have many states.

  Consider you have an account activity page, that list transactions, by date, author, price, etc. If you update the account, all the fragments of the grid view should be expired by iterating over all the possible keys: accounts/1/activity?sort_by=date&page=1 accounts/1/activity?sort_by=date&page=2 accounts/1/activity?sort_by=price&page=1 ... Iterating over the keys is O(n). By using a second key, as a version indicator, in the fragment key this expiry routine can be cut down to O(1). version_key = Rails.cache.fetch(“versions/accounts/1”) do { Time.now.to_i } cache_key = {:page => params[:page], :sort_by => params[:sort_by], :version => version_key, :controller => ‘accounts’, :action => ‘activity’ } This generates keys like: accounts/1/activity?sort_by=date&page=1&version=1217266122 accounts/1/activity?sort_by=date&page=2&version=1217266122 ...

  When the account is updated in this case, only the version_key needs to be expired to invalidate all the view fragments.

• tobias Lütke 10 Aug 09:47

  Wow matthew, thats really clever. Really nice application of the generational idea. Of course it would require multiple lookups of keys in memcached but this could probably be reduced to two using multi_get.

  Roob: ProFontWindows 9pt

Name

Email

Homepage