Ayende @ Rahien

It's a girl

The RavenDB caching solution

One of the more interesting aspects of Raccoon Blog is that we have done absolutely no performance work on the blog at all. Nevertheless, one of the most common items of feedback was that it feels much faster.

There are actually two reasons for that. The first is that unlike relational databases, we model the data so loading each page is usually just a single query to the database. The second is that RavenDB has been designed to be very cache friendly.

Think about this, if you are using something like Entity Framework or Linq to Sql , you are basically out on your own with regards to a caching solution. With NHibernate, there is a builtin option, but that one is:

  • Disabled by default (rightfully so).
  • Easy to get wrong.
  • Usually takes me two hours to explain just this topic in my course.

In contrast to that, with RavenDB, caching is such an basic part of the system that we made it the default. Everything is cached by default (actually, we have multiple levels of caching, both on the client and on the server, but that is beside the point). The end result is that for the vast majority of cases, we only need to check if we are up to date, and all the data is already in the local cache.

I built this feature just for this scenario, but because it is on by default, I never actually thought about this, we just worked as we normally would, focusing on features, and RavenDB took care of the performance.

Posted By: Ayende Rahien

Published at

Originally posted at

Comments

meisinger
05/17/2011 04:57 PM by
meisinger

just a quick question on the cache strategy... i am assuming that client checks with the server to see if the content (or document) has been updated or is out-of-sync; (of course if this assumption is wrong then the question is moot)

working with this assumption, does the client actively pull the latest from the server or simply "clear itself out" awaiting the next request?

in other words, does the client update the content within the same request or does it simply send what it has currently and upon the next request update itself?

just curious

Sean Kearon
05/17/2011 05:25 PM by
Sean Kearon

Yes, it is definitely faster!

João P. Bragança
05/17/2011 06:35 PM by
João P. Bragança

meisinger,

iirc it's mostly done through etag caching. Every document gets an etag, which implemented here is a sequential guid. Client sends etag with the request, if they match then raven returns 304 not modified.

jdn
05/17/2011 11:08 PM by
jdn

That is pretty sweet.

Matt Warren
05/18/2011 08:39 AM by
Matt Warren

There's more info on how RavenDB caches doc here http://ayende.com/blog/4748/ravendb-http-caching

Ayende Rahien
05/19/2011 09:07 AM by
Ayende Rahien

meisinger, It checks with the server whenever a query is made, to check if the query result (or the document being loaded) is already in the client cache. The way it work, you'll never get cached information that is out of date.

Chris Lawson
05/20/2011 06:43 PM by
Chris Lawson

There are numerous external links to your (old) site to download Rhino Mocks for Silverlight. Is this port still available for download? I check the 'recent builds' link, but being from the older 3.5 version, it's not in the list.

Thanks,

Chris

Ryan Hoffman
05/22/2011 06:56 AM by
Ryan Hoffman

I have to say, raccoonblog is clearly the fastest serving pages then any other blog engine I've ever seen. It's a great example of the power of RavenDB. All of these great features that RavenDB provides makes a really compelling argument for people to start jumping on board.

Ayende Rahien
05/22/2011 08:52 AM by
Ayende Rahien

http://hibernatingrhinos.com/open-source/rhino-mocks

Comments have been closed on this topic.