Skip to main content

What cache mechanism to use from Windows Azure

Yesterday, I had a talk with one college about cache mechanism. The true is that Microsoft has a lot of cache mechanism and when we talk about Windows Azure we have so different mechanism that there are times when we don’t know what the best cache mechanism for us is.
We will talk about 3 times of cache mechanism that are supported by Windows Azure:
  • Windows Azure Appfabric Cache (specials service defined by Windows Azure)
  • Co-located Role Caching (in-memory cache – resources are shared between cache and hosted applications)
  • Cache Worker role (dedicate role used only for cache)
From my perspective we have a lot of options. What we should know from the begging about Windows Azure Appfabric Cache is that be used in combination with Windows Azure of course, but from what I saw until now we cannot have a combination between co-located role caching and Windows Appfabric Azure Cache or Cache Worker role and Windows AzureAppfabric Cache.
Why we cannot combine them? Because the last two cache mechanism offed by Windows Azure can be accessed only from the deployments roles (NOTE: A deployment can have 1...n number of applications and roles). Because of this we cannot make this type of combination.
Windows Azure Appfabric Cache is a good solution when we need a cache mechanism that needs to be shared between different servers. It is not mandatory all servers to be hosted by Windows Azure. Using this cache mechanism we will be able to use our cache from any machine in the world that has internet connection. Don’t forget about an important think about this cache mechanism. Any machine that has the credentials of our cache can access it.
The other to cache mechanisms is very powerful mechanism that can be used by our application. When we need a cache mechanism for our application to be used only by our application I think that this caches are the best. What do decide to use? Co-location caching or cache worker role. The decision is not very simple. The good part is that the switching between them is very simple. Using the configuration file of our application we can very easy change the cache mechanism. Only when we make a switch between this and Windows AzureAppfabric Cache, in some case we will need to add some assemblies, but the API are very similar.
If we have a simple application, that doesn’t consume many resources; we can start with Co-located role caching. If the size of cache increase or/and resources that are used by our application increase also we could switch to Cache worker role. When we use the Cache worker role, we will have a dedicated role used only for cache. For a medium or big application this could be a better solution. Our resources of the roles will not be shared with the cache and also we will know that we will have a dedicated role only for cache.
But if we will have only a Cache worker role what will happen if the role crash. We will lose all data from cache. An option is to activate the automatic backup that will be made on our storage account. In this way the cache will be back-up automatically and restore when is needed. But until the role is restored we will have a period of time when the cache will be down. Also the cache data that is restored could not be with the last cache data (not all data from cache is backup in real time).
From what we saw, if we begin to use Cache worker role, a good decisions it would be to use two instances of Cache worker role if we want to be sure that we have a good uptime. But from my experiences, it is not very often that a role crash because of Microsoft. I n the case we have applications that dependents of crash and need to be up 100% of time use two instances of Cache worker roles of co-located cache.
If you have some data that need to be used only by one role from the application (for example some client information) than Co-located role cache could be a better solution. The time necessary to access this cache is the lowest one because the data are in the memory of the role (in general). Because you can define more caches (by name) in the same Co-located role you can group the data from that need to be stored in the cache.
It is not very simple to decide what cache mechanism to use from Windows Azure. If we need a cache mechanism that is used by different application, Windows Azure Cache can be a good decision, but is hard to decide to decide what to use between Co-located role cache and Cache worker role. For medium to big application I recommend Cache worker role. At start is okay to use Co-located role but after make a switch to Cache worker role. If you have application that doesn’t use all the resources of your role that Co-located role could help you to save some money. Don’t forget that the switch between these cache mechanisms is very easy. Almost all can be done from the configuration file.


Post a Comment

Popular posts from this blog

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Entity Framework (EF) TransactionScope vs Database.BeginTransaction

In today blog post we will talk a little about a new feature that is available on EF6+ related to Transactions.
Until now, when we had to use transaction we used ‘TransactionScope’. It works great and I would say that is something that is now in our blood.
using (var scope = new TransactionScope(TransactionScopeOption.Required)) { using (SqlConnection conn = new SqlConnection("...")) { conn.Open(); SqlCommand sqlCommand = new SqlCommand(); sqlCommand.Connection = conn; sqlCommand.CommandText = ... sqlCommand.ExecuteNonQuery(); ... } scope.Complete(); } Starting with EF6.0 we have a new way to work with transactions. The new approach is based on Database.BeginTransaction(), Database.Rollback(), Database.Commit(). Yes, no more TransactionScope.
In the followi…

GET call of REST API that contains '/'-slash character in the value of a parameter

Let’s assume that we have the following scenario: I have a public HTTP endpoint and I need to post some content using GET command. One of the parameters contains special characters like “\” and “/”. If the endpoint is an ApiController than you may have problems if you encode the parameter using the http encoder.
using (var httpClient = new HttpClient()) { httpClient.BaseAddress = baseUrl; Task<HttpResponseMessage> response = httpClient.GetAsync(string.Format("api/foo/{0}", "qwert/qwerqwer"))); response.Wait(); response.Result.EnsureSuccessStatusCode(); } One possible solution would be to encode the query parameter using UrlTokenEncode method of HttpServerUtility class and GetBytes method ofUTF8. In this way you would get the array of bytes of the parameter and encode them as a url token.
The following code show to you how you could write the encode and decode methods.