Todd Robinson

Just last week it was announced that Windows Azure AppFabric Cache is now in production. That is great news for folks who are looking to add some caching to their Azure apps. The only thing I read that concerned me was the pricing. It starts out at $45 for a small 128 MB cache and goes all the way up to $325 for 4 GB. After reading the FAQ, you’ll see that there are limits to the amount of transactions, bandwidth, and concurrent connections as well at the different sizes. Once I read the FAQ though, I can see where this is an excellent value if you’re not wanting to invest in your own equipment to run and properly size your own local Windows AppFabric Cache instance. I will have to do some further research, but I imagine that the hardware requirements to be able to do the amount of transactions and bandwidth at the upper limit of the 4 GB plan would be pretty expensive. In any case, Microsoft will not start charging for this service until August 1st, 2011. If you are thinking about getting started with Azure AppFabric Caching, you can sign up for a free trial introductory offer.

I will be presenting my talk on Windows AppFabric Cache and SQL Server 2008 on Friday, May 13th at SQLRally.This will be a 200-level session where I will go over some of the basics of caching technologies (NoSQL), who uses them, and why. I will then go into describing Windows AppFabric Cache and how its used to help with performance in concert with SQL Server. I will have a few basic demo’s that show how easy it is to integrate into an existing applications as well as its speed. My goal is to have you after the session thinking about ways to integrate this into your environment to solve some painful issues.

I’ve been notified that my Chalk-Talk session, AppFabric Cache and SQL Server 2008, has been selected for this years PASS summit. Here is the abstract that I submitted:

With all the hype about NoSQL going around in the SQL community its about time we looked at a Microsoft’s distributed cache-aside solution, AppFabric Cache. In this session we will briefly go over what AppFabric Cache is, what it can and cannot do, as well as some of the compelling features that make it a complimentary product to SQL Server. We will go over some real-world examples on how AppFabric Cache can co-exist with SQL Server and increase performance. In addition, we will compare the speed of the AppFabric Cache in comparison to SQL Server 2008  in both queries and inserts/updates. This chalk-talk will go more in-depth into some of the information presented in the SQLCAT Optimizing application workload & performance by leveraging AppFabric Cache along with SQL Server session.

Looks like I’ll be practicing nothing but AppFabric from now until the conference!

In my testing with AppFabric Cache I’ve been comparing its performance against SQL Server 2008 R2. In just about all use cases, AppFabric Cache is kicking SQL’s butt, except for one, in what I call the “BulkPut”.

In my testing scenario, I receive messages that I have to process which contain 1 to 100 items. There are two types of messages. One message contains all updates, and the other contains all queries. The schema of the database is similar to what gets put into the AppFabric Cache, in that I simply have a key and the object, which in this case is the serialized portion of the message. When I perform the updates in AppFabric Cache, I use the Put command, and when doing the queries, I use the BulkGet. In SQL Server 2008 R2, for both updates and queries I use a stored procedure which accepts a Table Valued Parameter (TVP). This allows me to send the 1 to 100 items in one shot to the stored procedure.

First, lets see the numbers for the queries:

As you can see, both sets of data are fairly linear, and you can clearly see the cost of making the connection to SQL, translating the SQL request to get the key and its object, then returning it. Overall, AppFabric cache is 3 to 6 times faster in retrieving the same data.

Now, if we look at the numbers for the updates:

Now we see that being able to supply the items in bulk to the TVP in SQL Server allows us to beat out the AppFabric Cache which has to do the Put command serially, or as my SQL folks out there would say RBAR (Row by agonizing row). This is why I would love to see a BulkPut command in AppFabric so I can jsut send it a bunch of changes that occur in the same region, similar to the BulkGet request.

Now I’m sure some of you could code circles around me and just use multi-threading or the parallelism in .Net 4.0 to make the updates in AppFabric Cache just as good if not better than the results I get out of the database, but that’s not the point of this exercise. I just wanted to use the best native way I knew how to get the data in and out of the cache and the database in the most efficient, single threaded way I knew possible. Hopefully, something like a “BulkPut” will be put into AppFabric Cache here sometime in the future.

On twitter today I saw some discussions about caching in regards to databases. Included in those discussions were talks about NoSQL, such as MongoDB. Here’s my take on the subject. SQL Server has a built in caching mechanism which takes data, execution plans, etc. and keeps them resident in memory. If you have much more memory than data, chances are that all the requested pages will keep themselves available. All flavors of NoSQL can be thought of as simply a way of storing data in memory, most often in key-value pairs. If you are trying to do simple key value lookups, from both a database and say my favorite flavor of NoSQL, AppFabric Cache, the response time is going to be eerily similar. The reason for that is you are looking for the key in memory in both cases, and returning the “payload”, which is the columns in the database or the value in the cache. The reason the SQL Server takes a bit longer is that it has to “translate” your SQL into a request to get the information, where as in AppFabric Cache, you are simply making a request for the value which corresponds to that key. In my testing, I found that responses from AppFabric Cache on average took .4ms and the same request from the SQL Server database took .6ms. Both of these were simple key value lookups, and the data from SQL Server had already been cached. The extra .2ms can be thought of as the overhead of translating the SQL and putting together the response.

After my startling findings using AppFabric cache and tweeting about it, I’ve been called to the mat by none other than two SQL stalwarts, Buck Woody (@buckwoody) and Steve Jones (@way0utwest). Apparently they require proof-of-life for such claims and I’ve been debating on how best to present it. I could

1) Write a blog post about it
2) Write an article about it
3) Create a presentation

The fact is, there is just way too much information to make a single blog post about it. I would have to break it up into multiple parts and I wouldn’t be able to do it justice. Similarly, for an article, I still feel as though I’d be leaving information out. I have to give the back-story as to the problem we are trying to solve. While it can be done, I feel as though I would spend as much time writing about the problem as I would at what I did to solve it. AppFabric Cache should be the star.

I’ve decided that making a presentation for the AppDev Virtual Chapter at PASS would be the best route. This way I can spend a few slides on how things work today using diagrams and pretty pictures, and then delve into the meat and potatoes of how I used AppFabric Cache to do the work of 60+ servers on one laptop.

Now the fun part is going to be de-classifying the information and make it generic enough for public consumption.

Alternatively I suppose I could make everyone wear a pair of these censor glasses…

I finally got the entire project running and got the metrics I needed in order to do my presentation next week. I managed to take 15.6 million records and push them into the cache, performed 6.3 million key lookups, and 800k region lookups with tags in just under one hour. All on my laptop!!! This same workload was captured from an hours worth of processing from 64 application servers with 5 database servers. So far, I’m very much impressed. More details of this to follow when I can produce examples for public consumption.

I ran across this nifty Codeplex project the other day which puts a nice graphical interface onto the AppFabric Distributed Cache PowerShell scripts. Now instead of opening up a PS window to get everything started, I simply launch this tool and it starts up the cache for me. It allows you to manage items at the Cluster, Host, Name, and even down to the Region.

To download, go to http://mdcadmintool.codeplex.com/releases/view/44428

The release candidate of Windows Server AppFabric is now available for download at http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=a9b94a33-2ec2-4439-902f-813539cf42d2

Please remember that if you are running previous versions such as Beta1 and Beta2 that you will need to uninstall the AppFabric Beta first, and then remove any RC versions of .Net before attempting the install. Please read the ReleaseNotes.docx for more information.