locked
Role-based caching in Windows Azure with the Compute Emulator RRS feed

  • Question

  • When a new instance my Web role is launched using the VS (F5) debugger, it appears as though my (co-located) cache is cleared as the Web role is spun up. I'm adding items into the DataCacheFactory default cache. I am guessing this is the normal behavior. I am reading that items remain in the cache for 48 hours by default, otherwise, unless explicitly set so I was trying to emulate this behavior between sessions. In the cloud I would assume as long as there were two vms for the Web role instance then it would safely fail over, but wanted to confirm that also.


    Thanks!

    Thursday, August 8, 2013 2:34 AM

Answers

  • Hi,

      >> When a new instance my Web role is launched using the VS (F5) debugger, it appears as though my (co-located) cache is cleared as the Web role is spun up.

    From my experience, in Compute Emulator, after a role is destroyed, all instances (simulated as processes) are destroyed, thus memory is reclaimed, and any in-memory cache is lost. This will also happen in the cloud if you completely redeploy your solution (so all instances are destroyed). If you do an in place upgrade, and if you have multiple instances, some of the co-located cache may preserve, but some may lose, because in co-located cache, there is no telling if cache is duplicate on all instances and in most cases it won't. I'd like to point out that actually reading from another instance is almost as fast as reading from local memory since the network within a data center is very fast, thus we do not have to duplicate cache. Also, this will reduce the memory available for caching, if you use dedicated cache, as long as the cache role is not updated, data would not lose. But occasionally data lose may still happen, as the cache instance may encounter error and has to be moved to another node, or the hosting OS needs to be updated and restarted. 

    So to sum up, cache is not meant to store permanent data. It is recommended to store permanent data in an external storage, such as Windows Azure storage or SQL Database.

    Best Regards,

    Ming Xu


    Ming Xu
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, August 8, 2013 1:29 PM

All replies

  • Hi,

      >> When a new instance my Web role is launched using the VS (F5) debugger, it appears as though my (co-located) cache is cleared as the Web role is spun up.

    From my experience, in Compute Emulator, after a role is destroyed, all instances (simulated as processes) are destroyed, thus memory is reclaimed, and any in-memory cache is lost. This will also happen in the cloud if you completely redeploy your solution (so all instances are destroyed). If you do an in place upgrade, and if you have multiple instances, some of the co-located cache may preserve, but some may lose, because in co-located cache, there is no telling if cache is duplicate on all instances and in most cases it won't. I'd like to point out that actually reading from another instance is almost as fast as reading from local memory since the network within a data center is very fast, thus we do not have to duplicate cache. Also, this will reduce the memory available for caching, if you use dedicated cache, as long as the cache role is not updated, data would not lose. But occasionally data lose may still happen, as the cache instance may encounter error and has to be moved to another node, or the hosting OS needs to be updated and restarted. 

    So to sum up, cache is not meant to store permanent data. It is recommended to store permanent data in an external storage, such as Windows Azure storage or SQL Database.

    Best Regards,

    Ming Xu


    Ming Xu
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, August 8, 2013 1:29 PM
  • Ming Xu:

    First and foremost, thank you for your thorough response.

    I'm not concerned about permanent data. I realize that permanent data does not belong in the cache and would not attempt to store it there. I was thinking more in the lines of storing important state-driven information (session-state) in the cache cluster. You mentioned that the co-located cache is not duplicated (or at least guaranteed to be duplicated). I am assuming, but wanted to be careful about assuming, that you are talking about a non-HA scenario. My understanding is that I can create a co-located cache cluster with HA (across four roles, recommended,  IIRC) in the project settings and this would commit cache writes on all nodes in the event of one's failure. Is HA a general best practice to ensure session reliability?

    Mark

    Thursday, August 22, 2013 1:52 AM
  • Hi Mark,

      >> I was thinking more in the lines of storing important state-driven information (session-state) in the cache cluster.

    I am not sure about what you mean by HA. In general, it is recommended to use as little session as possible. Session was heavily used by server centric web applications because they had to store client states (Whenever user initiates a simple interaction, a completely new web page is served. States are not preserved on the client side). But even web applications have moved to client centric these days. States are stored on the client, and will not be lost unless the browser crashes. So session is used less and less often.

    If it is needed to use session on your side, then please make sure your application works in case of session loss. We can't guarantee session state is persisted, unless we store the data in, for example, a database. Like I pointed out in my previous reply, cache is a convenient way to store temporary data. Those data can be fetched very fast, but are not duplicated (to save memory for more cache items).

    Best Regards,

    Ming Xu


    <THE CONTENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED>
    Thanks
    MSDN Community Support

    Please remember to "Mark as Answer" the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.

    Thursday, August 22, 2013 3:13 PM
  • Windows Azure offers HA caching, yes? It's documented and appears as an option in the role caching configuration. Per my understanding this does duplicate the cache on every node in the cluster.

    Wednesday, August 28, 2013 1:37 PM
  • Hi,

       Items remains in the cache based on the expiration setting and eviction policy on the named cache that you're setting, in this case 'default'. The default value is not 48 hours, so data won't be staying for 48 hours unless you set that value explicitly.

       Cache service is a distributed service which encompasses the RAM from all the instances running and collate to give an abstracted large RAM where people can store serialized data stream and retrieve. Since it's RAM is volatile, cache service is also volatile.

       To enable backup copies, you need to enable HA option (in the cache role settings page in VS) for the named cache. You need to have more than one instance for HA to be available though. Azure caching will ensure the backup copies will reside in a node other than the primary node, so even if the primary node goes down the secondary will act as a primary. So unless you enable HA you can't safely fail over.

    • Proposed as answer by Ashish Goyal Friday, August 30, 2013 7:28 AM
    Thursday, August 29, 2013 1:22 PM