Caching Preview role visibility

Question

The new Caching Preview just announced sounds quite powerful. I'm curious how visible the caches are within my Azure services. Is it limited to roles in the same Subscription, or the same Hosted Service, or the same Deployment, or something else? 

Also, does it make any difference if I set up the cache on a dedicated role, vs using memory on existing roles?

Answer 1

Hi, Brian,

Did you read this document? I think that it contains answers for all of your questions. Buddy of mine says that he tried to use new Caching and it was wonderful experience.

http://www.windowsazure.com/en-us/develop/net/how-to-guides/cache/

Answer 2

"To access a Windows Azure Caching (Preview) cache, the clients must be within the same deployment. If the cache cluster is a dedicated role cache cluster, then the clients are other roles in the deployment. If the cache cluster is a co-located role cache cluster, then the clients could be either the other roles in the deployment, or the roles themselves that host the cache cluster."

So it is limited to the same deployment.

Answer 3

OK, well that's the correct answer anyway. 

It infuriates me that Microsoft made this design decision. I'm sure that works fine in demo projects, but it's not terribly practical in a real solution. We've got web roles that change daily, and worker roles that virtually never change, all using the same data. If I want to use caching, then I need to redeploy every bit of the service, every time anything changes. Need to change a bit of logic on the website? Then you get to kill of everything in your service. Those 8 workers roles that were unaffected, and were in the middle of a 10-minute-long job? Yeah, kill them too. 

Answer 4

And I forgot to mention, every time you load it clears out your entire cache. Who wants a warm cache anyway? Starting over with a cold cache every time is just as good, right? 

</sarcasm>

Answer 5

Hey Brian,

   If the worry is about warm/cold cache, then I think this information would be helpful. 

   Windows Azure Cache is well integrated with Windows Azure platform.  By that means, we have designed it for azure events such as Patch Tuesday, Rolling Upgrades.

   Whether is patch updates or your web role updates, if they are done in 'rolling upgrade' fashion; then role instanes go down gracefully.  When a node goes down gracefully, cached data is transferred over to other existing caching enabled roles.  Hence, your cache remains 'warm' even when your web roles are getting patched up, or OS is patched up.  However, this does not hold true in case of Stomp Deployment, etc. where the intention is to start a fresh and lose all the old state.

   The (*) in the above para is for:

   - If there is no memory on other cache enabled roels to accommodate the extra data coming from the nodes that are going down, then that data is lost

   - The unit of commit in transfer is partition (an internal entity).  If there is 100 MB of data in a partition, and the recepient of this partition has only 80 MB free memory we will lose 100 MB.  Hence, it is recommended to not load the server to their full memory capacity but leave some space.  Dedicated Capacity Planning Guide is the best guide to plan capacity.  If you follow that guide, then you are all setup for warm cache

Thanks,

Laxmi Narsimha Rao Oruganti

---

Please propose and mark as answer, if my post answered your question(s). All postings are as-is and confer no rights.

Answer 6

We like to load up a Staging deployment, test that it's working right, and then VIP Swap it into production. So every time we do that we would get a cold cache. Even worse, if we ran the new build for a while, then discovered a problem and switched back, we'd be switching in a cache with potentially out of date data in it. 

The whole thing is still amazing to me. Azure is just trying to replicate memcached, which has been in use for years and is about as dead simple as can be. This is the second try, and you still haven't gotten it right. The Preview is close, though. Make it visible across all my roles & deployment, and you'll be there. 

Answer 7

Hi,

I think you could use the AppFabric Caching then, It would be independant from your roles.

---

R.