If your application is running in a Cloud Service (Web/Worker Role) it’s very easy add caching to your application by using Windows Azure Caching:
Windows Azure Caching introduces a new way to perform caching by using a portion of the memory of the virtual machines that host the role instances in your Windows Azure cloud services (also known as hosted services). You have greater flexibility in terms of deployment options, the caches can be very large in size and have no cache specific quota restrictions.
The .NET libraries depend on a library which is specific to Cloud Services, which makes them unable to use in Windows Azure Web Sites. This restriction applies to the official Windows Azure Caching libraries for .NET. But Windows Azure Caching also supports the memcache protocol, this means you can use it from any environment supporting memcache like Node.js, php, …
Let’s see how we can configure the memcache protocol in Windows Azure Caching, open it up for Windows Azure Web Sites and call it from a Node.js application.
Memcache support for Windows Azure Caching
We start by creating a new Dedicated Cache Worker Role as described here. Once this is done we’ll add support for the memcache protocol by using the Memcache Server Gateway. The Client Shim is not an option here since it requires an installation on the consumer side: in our case this is the Web Site and Web Sites don’t support running custom installations at the moment (remember that you’re running in a shared hosting model).
Setting up the Memcache Server Gateway is pretty easy: add an endpoint called memcache_default to your Cache Worker Role (you can choose the port):
Allowing access from your Web Site
When using Windows Azure Caching within a Cloud Service you typically set the endpoint type to Internal. But since the Web Site is not part of the Cloud Service you’ll need to change the endpoint to Input. It’s important to know that, by changing the type to Input, your Web Site will be able to connect to the endpoint just like everyone else with an internet connection.
Chances are pretty small that anyone will find this endpoint (by guessing/scanning the IP+port), connect to it, find out that it can be used by a memcache client and do something with the data. But it’s better to be safe than sorry so here is what you can do: you can use the WindowsAzure.IPAddressRestriction library to restrict access to the Worker Role. If you look at the Examples on GitHub there’s an example that shows you how to restrict access to your Worker Role endpoint(s) based on hostnames:
Once you’ve set up this code in your Worker Role you can configure the hostnames in your Service Configuration:
Using Windows Azure Caching from your Node.js Web Site
So we’ve set up Windows Azure Caching, added memcache support and made sure that (only) our Web Site can access the cache. Let’s get started on our Node.js application. The application will use the node-memcache library to access Windows Azure Caching through the memcache protocol. Here is the sample application:
The code is pretty straight forward. We reference the library, create the client and connect to the endpoint we opened in the Cloud Service. The get and set methods allow you interact with the cache. If you access the page the first time you’ll see that the value is added to the cache:
Each subsequent request will get the data from the cache:
And that’s about it. You’re all set up to use Windows Azure Caching through the memcache protocol which can drastically improve performance of your site.
Enjoy!