Velocity - Microsoft Distributed Cache
A couple of days ago, I was chatting with David, I have not blogged since 2004, Penton about the lack of a built in distributed caching solution for .NET. There are a couple of really good third party tools available (more posts coming soon) but since caching adds such a huge boost in performance (if used correctly) it is really struck me as odd that the folks in Redmond had not yet addressed this issue on their own (I do not need a Microsoft certified solution to every problem, but since that is their style, it seemed to odd to be missing one here).
However, while I was catching up on what had been announced at Tech-Ed I came across a mention of Velocity.
“Velocity” is a distributed in-memory application cache platform for developing scalable, available, and high-performance applications. Using “Velocity,” applications can store any serializable CLR object without concern for where the object gets stored because data is cached across multiple computers. “Velocity” allows copies of data to be stored across the cache cluster, protecting data against failures. It can be configured to run as a service accessed over the network or can be run embedded with the distributed application. “Velocity” includes an ASP.NET session provider object enabling storage of ASP.NET session objects in the distributed cache without having to write to databases, which increases the performance and scalability of ASP.NET applications.
As I mentioned before, there are a couple pre-existing tools:
- Memcached - The granddaddy of them all. Simple, used everywhere (I mean, EVERYWHERE), and free.
- ScaleOut - Robust, fault tolerant distributed caching
- NCache - similar to ScaleOut but with a very annoying developer licensing model
- SharedCache - Open source managed code distributed caching
There is an interesting distinction between these tools. One on hand you have Memcached which treats the cache as something you should never rely on. It is there to help but you should always assume it is going to fail on you and even more importantly (to Memcached) you should accept that as a fact. If you read the Memcached FAQ you can almost here the author laughing when talking about fault tolerance. On the other side of the fence you have features like replication and high availability. It is just a CPT, but it looks like Velocity wants to be in the latter group.
I am still on the fence about which type of solution is most ideal. At first, I was in favor of the "high availability" group, but as I read up more on memcached their simplicity really started to grow on me. As with most other things, it will probably vary according to your applications needs.
I am planning on posting some sample code and patterns we are thinking about soon. So far, in light testing, I like Velocity and I will certainly write about it some more.
Anyone else in the .NET world using distributed caching? What is your tool of choice? Any tools I am missing?
Similar Posts
- ASP.Net Quick Tips - Caching
- Distributed Caching - Strategies and Tips
- Setting Up Velocity (Distributed Cache)
-
As I previously wrote, Velocity is Microsoft’s entry into Distributed Caching . It is currently in its first public CPT, so there are certainly going to be some rough spots. The documentation is pretty good, but setting it up and using it the first time
-
Havok, ya disponible gratuitamente : El motor de físicas más empleado en el mundo de los videojuegos
-
As mentioned previously, I have been spending quite a bit of time working distributed caching for .NET ( Community Server in particular). There are two main commercial players in the .NET space (prior to Microsoft announcing Velocity) ScaleOut and NCache
-
General The Design Is Never Right The First Time : This is hands down the best reason why an iterative approach to software development is the way to go...get something working in front of the decision makers early and often. Phil Haack presents an example
-
This week at TechEd Microsoft announce the Velocity project , a distributed in-memory object caching
-
Enjoying cup of Starbucks and Deep Purple Live in Stockholm 1970 (via Zune marketplace). WCF/WF My good
-
You've been kicked (a good thing) - Trackback from DotNetKicks.com
-
h2.entry-title { font-size: 1.1em; clear: left; } ul.hfeed { list-style-type: none; } li.xfolkentry
Comments
Jake Good on on 6.04.2008 at 10:05 AM
memcache is fantastic... and I want to touch on your point of fault tolerance...
It's a cache... caches are good for storing things you need... but you should never rely on a cache to not fail or for the data to be there... otherwise you'd just use it as your storage medium
And btw, using memory as a storage medium is starting to look solid with our large RAM machines...
Scott Watermasysk on on 6.04.2008 at 10:20 AM
@Jake - Agreed on "it's a cache". If you are trying to maximize requests/response times, memcahced is probably the way to go.
If you are worried about versioning and other enterprisey things, Velocity/ScaleOut will probably be helpful.
Kieran Benton on on 6.04.2008 at 11:02 AM
Again completely agree with you. The whole point of cache is that it is lightening fast and removes overhead from more complicated parts of your architecture. If you start making it reliable then you sacrifice both of these core goals.
This is what makes Memcached so brilliant.
foobar on on 6.04.2008 at 11:03 AM
FINALLY. I've been wondering if MS was ever going to tackle this. Considering the numerous free, open source solutions available in Java, this was a huge hole in .NET's feature set.
foobar on on 6.04.2008 at 11:11 AM
Oh, add Gigaspaces and Coherence to your list of distributed caches available to .NET
Neil on on 6.04.2008 at 12:51 PM
Just rolled out memcached on a site site, load balanced across two servers. Worked an absolute charm.
Used the Win32 port and a provider over at CodeProject: http://www.codeproject.com/KB/aspnet/memcached_aspnet.aspx.
Alex on on 6.04.2008 at 3:04 PM
Gigaspace is still too bleeding edge on the .NET side. We just abandoned it for a project that was to interoperate with Java. Every release they would send us had numerous new bugs, and most of the features didn't work in .NET. It killed the project. We were their beta testers. Give them time to build a real QA dept.
Peter McKlear on on 6.07.2008 at 1:44 AM
We've rolled out several applications already with GigaSpaces and we really like their .NET product.
Aaron on on 6.08.2008 at 7:04 PM
I agree that you shouldn't rely on a cache to never fail, but that doesn't mean your cache can't be resilient to certain types of failures. If a cache doesn't have an item my behavior is likely to be looking in a persistent store, but why do I care if the item I'm looking for is stored in two places rather than one. I think the times you care about this are when it impacts your ability to retrieve data efficiently.
Also to this point you have to be careful when talking about static data vs. dynamic data. If all you do is pull out information that's reasonably static or immutable, simple caches are perfect. If you have data that changes frequently and needs propery versioning or concurrency management then you either (a) give up on that idea, (b) find a concurrency strategy that works with your cache solution or (c) find a cache that addresses those needs.
I'd be careful of promoting one-size fits all designs. There are reasons for what will be called "enterprise-class" cache systems and I think it has nothing to do with enterprise and more to do with a different interaction paradigm.
mycall on on 6.14.2008 at 1:38 AM
Beware of naive algorithms. Take naive Bayes classifier for example -- it is useful but not even close as good as more advanced algorithms. The same goes for memcache.
Hadi on on 6.16.2008 at 5:47 AM
Well I have seen all these solutions but found NCache as the best one becuase no other solution is available for Object Caching. I was comparing the CTP1 of Microsoft's Velocity and to my surprise they almost copied the wordings of NCache's description. I had also compared the detailed features so far discussed by Velocity at TechEd with all these solutions and again found NCache a step ahead.
The pricing is not that complex. Its only the way you understand it. I have bought it for 15 CPUs and so far have been getting excellent support from this company. I had a comprehensive demo and testing as well where they showed 100%. The big plus of NCache is that they have always been bringing new topologies which are still missing with other solutions.
I am not sure what will be Licensing structure of Microsoft for this as Microsoft has always been very clever in their Licensing structures. I had bought some Licenses of Microsoft GP for my organization few months ago. The actual cost was way different from the one initially told. The basic structure has so many features missing. When I asked for some common features I was heavily charged. I am worried that they may repeat the same here as well.
Joey Simhon on on 6.24.2008 at 8:59 AM
I think one of the biggest things we've missed on the ASP.Net developers community was a solid distributed caching solution similar to memcached. Such community driven solutions to some of the common scalability and performance issues could dramatically improve the adoption of .Net for large scale web applications.
We've tried using memcached win32 port for one of our projects but it failed and crashed during stress test and proved unusable that way.
Since we didn't want to go into hosting Windows & Linux machines side by side plus we had undesed hardware (=web server memory), we've join the SharedCache project and gave an helping hand in order to turn it to the "memcached for .Net".
We're currently working on the first large production deployment of SharedCache.
I'm worried that Microsoft is aiming at another bloated licensing model that will prevent us from adopting Velocity for fast growing non-enterprise web solutions.