Introducing "Velocity"

During the October 2008 PDC conference, the CTP 2 of Microsoft code name project “Velocity” was announced. “Velocity” is targeting CTP3 for MIX ’09 in mid-March, and RTM is schedule for middle of the year. V1 of Velocity will be free available!

But what is “Velocity”?

“Velocity” is a distributed caching product that provides support for developing highly performant, scalable and highly available .NET applications.  Velocity can be installed on multiple servers, known as cache servers, which all together form the cache cluster. The server can be a web or an application server.

When a client application is accessing the cache it is not aware that this is a distributed cache; it is accessing it as a unified cache, it doesn’t know how many machine are in the cache cluster; what data resides on which machine; so the applications are not aware that this is a distributed cache.

As a cache, Velocity allows any types of data to be cached. In fact velocity does not make any assumptions on the type of data; you as a developer you have to tell what it has to cache: CRL objects, XML, binary data , … The only requirement is that the object is serializable.

The fact that “Velocity” is an in-memory cache it guarantees high performance requirements of applications. The fact that “Velocity” offers partitioned cache (data is partitioned between different machines within the cache cluster), allows you to scale on increased data by just increasing the number of machines within the cache clusters. This of course increases also the performance.  And this is not everything. In fact it is also possible to maintain different copies of data on multiple cache servers, which means that “Velocity” also offers high availability (a feature that can be easily enabled or disabled). If one machine go down, a copy of the data is available on another machine.

When you build your application using “Velocity”, you have to think about everything: with that I mean that if your data is not present in the cache, your application and not the “Velocity” distributed cache, must reload the data into the cache from the original data source. There is no automatics synchronization mechanism between the data source (for instance your DB) and the “Velocity” cache, no automatic notification mechanism between the data source and the caching layer.

Where can I use “Velocity”? Probably one the most interesting use cases for “Velocity” is the ASP.NET scenario. When you are writing an ASP.NET application, scaling your SessionState has always been a big issue (we can just have a single StateServer). Now with the “Velocity” there is a new provider called “SessionStoreProvider” which plug in the ASP.NET session store and therefore allow you to store session-state data into the “Velocity” distributed cache. By just putting a line within the web.config file of your application, your ASP.NET application will start to use the velocity service to cache your session state data.

I do not want to explain concepts like Named cache or Regions. All these and others concepts are well clarified within the official documentation, which can be found at

If you want to learn more, then the best place to start is probably:

There are also a couple of PDC sessions available:

TL14 Project "Velocity": A First Look Resources

Resources:  PPTX| ZIP
Download: WMV-HQ | WMV | Zune | MP4 


TL56 Project "Velocity": Under the Hood

Resources:  PPTX| ZIP
Download: WMV-HQ | WMV | Zune | MP4

Comments (2)

  1. roni_schuetz says:

    i def. agree to use velocity as session provider but for caching its to slow. if i compare (ctp 2) it to my shared cache project then my performance is still over 40% faster in my test. it would be interesting to see a Microsoft comparison between common caching solutions – even with caching vendors.

    reg, roni

Skip to main content