The first step to start using Velocity is to create a Cache Cluster: a group of one or more servers on which the service responsible for providing distributed cache will run. To demonstrate Velocity's key features we will use 3 servers: one for storing cache configuration settings and two as cache servers, on which Velocity service will run after being installed.

Figure 1: Cache Cluster

When installing Velocity on a cache server, a cluster configuration storage location must be specified, configuration includes a list of servers that are part of the cluster, tcp ports used for communications between cache services running on every server and other specific settings related to named caches created later. Three storage types are available for storing Velocity settings: xml-based file, SQL Compact edition (.sdf) and SQL Server which is the only cluster-aware, fault tolerant one.

For this demo, I opted for the third choice because it is a nearly real-world scenario and is easier to inspect tables created behind the scenes by Velocity.

Figure 2: Cache host setup

Cluster configuration and administration is provided by Powershell console commands, well described and enlisted on MSDN documentation.

To start the cluster, launch Powershell (with Administrative privileges) from a cache server and type:

start-cachecluster

Figure 3: Starting the cluster from Powershell console

Though it is now possible to use default cache, we proceed by creating a named cache, typing:

new-cache -CacheName CatalogCache -Secondaries 1 -TTL 15

With this command, a cache named "CatalogCache" will be created, leveraging 2 servers, primary and secondary. After an object is stored in a cache, a second copy will be stored on a secondary server and kept consistent, cache duration is configured to 15 minutes. To obtain some statistics about the cache we just created, type:

get-cachestatistics

Figure 4: get-cache and get-cachestatistics console output

Demo overview

The application used in the demo represents an online electronics shop where customers can browse a simplified product catalog and can add products to their shopping cart. Now let us suppose that loading the catalog is such as long-running operation, querying several heterogeneous data sources. For these reasons a cache strategy is suitable between Data Access Layer and data sources. The catalog became a good candidate to be stored in cache, increasing the application responsiveness and avoiding database roundtrips.

Note: Although the techniques used in the demo are similar to many real world scenarios, these are not the recommended way to manage an online catalog; it is only a demo.

Setting up development environment and start using Velocity

To start using Velocity in our applications, just add references to the following assemblies, picking them from Velocity’s installation folder from one of the cache servers.

Figure 5

Then add the Velocity namespace: Using System.Data.Caching;.

Here is a code listing used to access the named cache created previously. You can see that an array of ServerEndPoint is created first, representing our cluster, and then a CacheFactory is used to create a CacheClient which can be used to put and get objects in cache back and forth.

Listing 1

//Declaring cluster's servers
ServerEndPoint[] servers = new ServerEndPoint[2];
servers[0] = new ServerEndPoint("SERVER1", 22233, "distributedCacheService");
servers[1] = new ServerEndPoint("SERVER2", 22233, "distributedCacheService");
            
//Creating cacheFactory
CacheFactory factory = new CacheFactory(servers, true, false);
//Accessing named cache
Cache catalogCache = factory.GetCache("CatalogCache");
 
//Putting catalog into Velocity cache
catalogCache.Put("Catalog1", CatalogManager.GetCatalog("Catalog1"));

After putting the object in cache, it is then possible to retrieve it later.

Listing 2

//Getting catalog from Velocity cache
Catalog myCatalog = (Catalog)catalogCache.Get("Catalog1");

In the demo application, when the catalog is not in the cache, it is loaded from the database, once it is put in cache, the same catalog can be accessed from any web server in the farm. This is a different behavior from ASP.NET cache, in which every web server can access only its cache. You can look at the address bars in figure 5 and see that the catalog is browsed using 2 different servers, but the catalog is the same one loaded at the time displayed in the statistics box. This could happen because objects are not stored in the same AppDomain of the web application (as would happen using ASP.NET cache), but they are stored in Velocity cache which offer a unified view of memory of all servers in the cluster.

Figure 6: Same page from 2 different web servers, accessing the same Velocity cache

 Server 1

 Server 2