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:
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.
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)
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.
Thanks for the post, Radu. Nice work.
ReplyDelete