Regarding my previous post about Memcached, Zeddy pointed me to Project Velocity. This is exactly what I am looking for!. A highly scalable in-memory, distributed cache cluster in farm deployment, high availability and of course, concurrency ready and x64 support!. Applications can store any serializable CLR object without worrying about where the object gets stored. Scalability can be achieved by simply adding more cache servers on demand. “Velocity” also allows for copies of data to be stored across the cluster, thus protecting data against failures. “Velocity” can be configured to run as a service accessed over the network or can be run embedded with the distributed application.
Key Features
"Velocity" consists of a cluster of servers that communicate with each other to form a single, unified application cache system. A client application can communicate with one or more of the servers in the cluster to perform cache operations such as Get, Put, or Remove. Multiple client applications can work with the same cached objects that use any of the servers in the cache cluster. The primary components of the physical model consist of the cache server, the cache host Windows service, the cache cluster, the PowerShell-based cache administration tool, and the cluster configuration storage location. The following diagram shows how all these elements relate.
- Caches any serializable CLR object and provides access through simple cache APIs.
- Supports enterprise scale: tens to hundreds of computers – with unified cache view from clients
- Configurable to run as a service accessed over the network or run embedded with the application.
- Supports common cache configurations.
- Supports dynamic scaling by adding new nodes.
- Configurable number of backup copies to provide high availability.
- Automatic load balancing.
- Integration with administration and monitoring tools such as ETW, System Center, etc.
- Provides tight integration with ASP.NET to be able to cache ASP.NET session data
- Follows the cache-aside architecture (also known as Explicit Caching) for V1.
- Support for multiple client languages (for example, PHP, C#, C++, etc.).
Key Scenarios : Social Networking Site and Enterprise LOB
Not only for social networking scenarios, Velocity was designed to support enterprise application.
High Availability Model
The logical model of the cache cluster consists of named caches, regions, and cached objects. In the diagram, named caches span all the cache hosts in the cluster, but regions are limited to just one cache host in the cluster. The high availability feature supports continuous availability of your cached data by storing copies of cached data on separate cache hosts, as illustrated in the next diagram.
With high availability enabled on a multi-server cluster, your application can still retrieve its cached data if a cache server fails. A copy of each cached object or region is maintained on a separate cache host. The cache cluster manages maintenance of these copies and supplies them to your application if the primary copies are not available. No code changes are required to make your cache-enabled applications highly available.
All "Velocity" cache hosts use TCP/IP to communicate with each other and support the cache cluster. To function correctly, each cache server needs firewall exceptions to be configured for the cache host service. Three separate ports are used: the cluster port, the arbitration port, and the cache port.
Client Types
In order to store data in the cache on a cache cluster, the System.Data.Caching.CacheFactory.GetCache(System.String) method is used to return a Cache object for you to work with in application code. Once instantiated, this Cache object is referred to as the cache client.
There are two types of cache clients: routing and simple. Each cache client also has the option to store cached data locally, which is named local cache. These cache client options are specified in the application configuration settings.
Deployment Models
Velocity” can be deployed as a service or embedded within the application. In cache service, client applications access the Velocity cache through client APIs (TCP/IP or pipes), just like Memcached. In embedded mode, application (like ASP.NET) provides host for Velocity. The distributed cache runs as part of the application (or container) and the memory for the cache is shared with that of the application.
Microsoft project code named "Velocity" offers many options for specifying and storing the configuration details that are used by the cache cluster and the client application. Cache-based applications have the option of specifying configuration information programmatically or by using an application configuration file. There are three options available for storing cluster configuration settings: in XML, in a SQL Server Compact data file, or in a SQL Server 2005 or 2008.
Performance Test
Below is the test result for Velocity. The application consisted of simulating lots of users on many distributed client computers. Each user thread performs operations like Get, Put, and Remove on a 20K payload. It is a plot of throughput as the load gradually increased and also as new servers were added. The throughput increases as the load increases until it reaches saturation and stabilizes. At this point, if we add more servers, load balancing kicks in and the throughput increases again and the response time goes down.
How to Start
For now, just install the Velocity in your machine and explore the sample codes. You can also refer to the following sources. Part of it is already referenced in this post.
- Download Velocity CTP 2 and Sample Codes
- Microsoft Project Code Named “Velocity”
- Microsoft Project Code Named "Velocity" Team Blog
- Velocity MSDN Documentation
I will show you more about Velocity in my next post.
Cheers – RAM