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