Distributed Caching: Put your money in fast disk’s…no make that RAM

Velocity or AppFabric Caching Services as it has now been named is for me one of the more interesting products coming out of Microsoft recently, whilst currently a v1.0 product I suspect in the future it will give Coherence and GemFire a run for their money. Caching as we all know, has long been recognized as an effective mechanism for improving application performance by for example reducing the number of times that data is fetched from a database in favour of fetching it from RAM where the access times are significantly lower, there’s nothing new there. But Velocity, being a distributed cache provides additional capabilities that lead to many powerful scenarios for increasing not only application performance, but also resilience.

Whilst consulting for Microsoft Services, customers would often engage me around the question of optimizing performance, particularly for BizTalk. With BizTalk being an i/o intensive platform for many scenarios due to its transactional integrity, almost always part of the solution involved either tuning the database or SAN configuration or using more performant discs for the BizTalk MessageBox. My phrase was often “put your money in fast discs!” since the performance of BizTalk solutions is often directly related to the performance of the i/o system that the BizTalk databases sit on.

For a long time I’ve argued that this level of transactionality whilst extremely powerful is in fact not always required. The introduction of Velocity along with some other new additions to the Microsoft stack being imminently released should enable a shift from disc based i/o to RAM based i/o, thereby achieving higher performance for many application scenarios.

Because Velocity is a scalable distributed cache the data maybe redundantly persisted in-memory providing a significantly higher level of redundancy when compared with a single machine caching approach. There are many scenarios whereby this low-latency data access approach can hugely improve application performance, and once Velocity has query capability as well as write-thru/read-thru capabilities a lot of the same levels of transactional integrity will be available with the performance benefits of in-memory data access.

Looking forward, with the next major release of BizTalk (2009 R2 + 1) being built on top of AppFabric, it would seem there are plenty of scalability benefits that BizTalk could leverage from Velocity.

The new version of WF that ships in .NET 4.0 is significantly more performance than the previous version having being re-written from the ground up following on from the learnings of the previous version. Since WF 4.0 also allows for custom persistent providers to be developed, it would therefore seem likely that there is a good opportunity to write a Velocity persistance provider for WF thereby enabling significant performant improvements whilst maintaining a high level of resiliance around WF instance state. Further, given that BizTalk messages are immutable, persisting them in Velocity would also seem like a likely candidate. Some interesting architectural possibilities to take the BizTalk platform to the next level

Advertisements

~ by kevinsmi on December 2, 2009.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: