Microsoft Velocity
When applications service a large number of simultaneous users, the developer needs to take this into account and find ways to ease the application’s bottlenecks. One way to help speed up a stressed application is to load into memory resources that will be requested by multiple users. Reading from memory is much faster than reading from a hard drive or a database, so this can significantly speed up an application.
However, each computer contains a finite amount of memory, so there is a limit of how much data you can store there.Microsoft Distributed Cache (code named "Velocity") attempts to address this problem. It allows your code to store data in an in-memory cache and it allows that cache to be stored on multiple servers, thus increasing the amount of memory available for storage.Velocity even ships with a provider that allows you to store a web site's session state, making it possible to increase the amount of memory available to your session data.
Looks at David Giad's wonderful web cast.
The Cache Tier can easily slide between the Application/Web Tier and the Data Tier. This makes fast access to the data, than access the data from the Data Tier.
Applications can store any serializable CLR object without worrying about where the object gets stored. Scalability can be achieved by simply adding more computers 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. “Velocity” includes an ASP.NET session provider object that enables ASP.NET session objects to be stored in the distributed cache without having to write to databases. This increases the performance and scalability of ASP.NET applications.
Key Features of "Velocity"
- Caches any serializable CLR object and provides access through simple cache APIs.
- Supports enterprise scale: tens to hundreds of computers.
- 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 in the cache without having to write it to source databases. It can also be used as a cache for application data to be able to cache application data across the entire Web farm.
- Follows the cache-aside architecture (also known as Explicit Caching) for V1. That is, you must decide explicitly which objects to put/remove in your applications and “Velocity” does not synchronize with any source database automatically.
- Support for multiple client languages (for example, PHP, C#, C++, etc.).
Velocity Logical Hierarchy
Host
Physical process hosting Velocity instance
Named Caches
Can span across machines
Defined in the configuration file
Regions
Physically co-located Continer of Cache Items
May be implicit or explicit created
Cache Item
Key, Payload(Object), Tags, TTL, Timestamps, Version
Understanding the different types of data and their semantics helps to understand the different caching needs that come with usage of that data type.
Reference Data
Reference data is a version of the authoritative data. It is either a direct copy of the original data or aggregated and transformed from multiple data sources. Reference data is practically immutable—changing the reference data creates a new version of the reference data. Reference data is an ideal candidate for caching; because the reference data does not change so often, it can be shared across multiple applications or users, thereby increasing the scale and performance.
Consider a product catalog application aggregating product information across multiple data source applications. The most common operation on the catalog data is read (or browse); a typical catalog browse operation iterates over a large amount of product data, filters it, personalizes it, and then presents the selected data to the users.
Activity Data
Activity data is generated by the currently executing activity as part of a business transaction. The data originates as part of the business transaction and, at the close of the business transaction, it is retired to the data source as historical (or log) information.
Consider the shopping cart data in an online buying application. There is one exclusive shopping cart for each online buying session. During the buying session, the shopping cart is cached and updated with selected products. The shopping cart is visible and accessible only to the buying transaction. Upon checkout, once the payment is applied, the shopping cart is retired from the cache to a source application for further processing. Once the business transaction is processed by the source application, the shopping cart information is logged for auditing and historical purposes.
While the buying session is active, the shopping cart is accessed both for read and write but it is not shared. This exclusive nature of the activity data makes it suitable for distributed caching. To support large scalability of the buying application, the shopping carts can be distributed across the cluster of caches. Because the shopping carts are not shared, the set of shopping carts can be partitioned across the distributed cache.By dynamically configuring the distributed cache, the degree of scale can be controlled.
Resource Data
Both reference (shared read) and activity (exclusive write) data are ideal for caching, but not all application data falls into these two categories. There is data that is shared, concurrently read and written into, and accessed by a large number of transactions. Consider an inventory management application. The inventory of an item includes the description of the item and the current quantity. The quantity information is authoritative, volatile, and concurrently accessed by a large number of users for read/write. Such data is known as the resource data; the business logic (the order application logic) runs close to the resource data (such as quantity data). Resource data is usually collected in data stores. For performance reasons, in “Velocity,” it is cached in the application tier.
Named Cache as equivalent to a database. A named cache is used for storing a logical grouping of data. Also, all physical configurations and cache policies such as failover, expiration, eviction and so forth, are specified at this level. In a distributed cache scenario, all the applications that need to communicate to the same distributed cache must instantiate the same named cache.
A cluster or node can contain one or more named caches. An application may use one or more named caches based on the policies for the various caches. For example, activity data may be stored in a partitioned named cache that is partitioned while a reference data (a catalog for example) may be stored in a named cache that is replicated.
Regions are logical grouping of objects within a named cache. You can think of regions as equivalent to tables, although regions can also store arbitrary sets of key value pairs. Items within a region are guaranteed to reside on a single node and are the logical units for replication and node placement. A named cache consists of one of more regions.
"Velocity" ensures the validity of cache items by supporting expiration and eviction. When adding objects to the cache, it is possible to optionally specify a time to live (TTL). Expired objects are removed from the cache.
In a distributed architecture, because many clients work with the same data, it may be useful for a client to know when a cache item is changed by another client. Notifications can be set on a region or a cache item level. When set, a notification event is generated for any change (add, put, remove) to the region or cache items.
Reference Articles
