+972 52-548-6969
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.
Comments
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
Yes, it is definitely faster!
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.
That is pretty sweet.
There's more info on how RavenDB caches doc here http://ayende.com/blog/4748/ravendb-http-caching
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.
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
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.
http://hibernatingrhinos.com/open-source/rhino-mocks
Comment preview