Windows Azure: New Distributed, Dedicated, High Performance Cache Service + More Cool Improvements

This morning we released some great updates to Windows Azure.  These new capabilities include:

  • Dedicated Cache Service: Announcing the preview of our new distributed, dedicated, high performance cache service
  • AutoScale: Schedule-based auto-scaling for Web Sites and Virtual Machines and richer AutoScale history logs
  • Web Sites: New Web Server Logging Support to save HTTP Logs to Storage Accounts
  • Operation Logs: New Filtering options on top of Operation Logs

All of these improvements are now available to use immediately (note: some are still in preview).  Below are more details about them.

Windows Azure Cache Service: Preview of our new Distributed Cache Service

I’m excited today to announce the preview release of the new Windows Azure Cache Service – our latest service addition to Windows Azure. The new Windows Azure Cache Service enables you to easily deploy dedicated, high performance, distributed caches that you can use from your Windows Azure applications to store data in-memory and dramatically improve their scalability and performance.

The new Windows Azure Cache Service can be used by any type of Windows Azure application – including those hosted within Windows or Linux Virtual Machines, as well as those deployed as a Windows Azure Web Site and Windows Azure Cloud Services.  Support for Windows Azure Mobile Services will also be enabled in the future.

You can instantiate a dedicated instance of a Windows Azure Cache Service for each of your apps, or alternatively share a single Cache Service across multiple apps.  This later scenario is particularly useful when you wish to partition your cloud backend solutions into multiple deployment units – now they can all easily share and work with the same cached data.

Benefits of the Windows Azure Cache Service

Some of the benefits of the new Windows Azure Cache Service include:

  • Ability to use the Cache Service from any app type (VM, Web Site, Mobile Service, Cloud Service)
  • Each Cache Service instance is deployed within dedicated VMs that are separated/isolated from other customers – which means you get fast, predictable performance. 
  • There are no quotas or throttling behaviors with the Cache Service – you can access your dedicated Cache Service instances as much or as hard as you want. 
  • Each Cache Service instance you create can store (as of today’s preview) up to 150GB of in-memory data objects or content.  You can dynamically increase or shrink the memory used by a Cache Service instance without having to redeploy your apps. 
  • Web Sites, VMs and Cloud Service can retrieve objects from the Cache Service on average in about 1ms end-to-end (including the network round-trip to the cache service and back).  Items can be inserted into the cache in about ~1.2ms end-to-end (meaning the Web Site/VM/Cloud Service can persist the object in the remote Cache Service and gets the ACK back in 1.2ms end-to-end). 
  • Each Cache Service instance is run as a highly available service that is distributed across multiple servers.  This means that your Cache Service will remain up and available even if a server on which it is running crashes or if one of the VM instances needs to be upgraded for patching.
  • The VMs that the cache service instances run within are managed as a service by Windows Azure – which means we handle patching and service lifetime of the instances.  This allows you to focus on building great apps without having to worry about managing infrastructure details.
  • The new Cache Service supports the same .NET Cache API that we use today with the in-role cache option that we support with Cloud Services.  So code you’ve already written against that is compatible with the new managed Cache Service.
  • The new Cache Service comes with built-in provider support for ASP.NET Session State and ASP.NET Output Page Caching.  This enables you to easily scale-out your ASP.NET applications across multiple web servers and still share session state and/or cached page output regardless of which customer hit which server. 
  • The new Cache Service supports the ability to either use a separate Cache Service instance for each of your apps, or instead share a single Cache Service instance across multiple apps at once (which enables easy data sharing as well as app partitioning). This can be very useful for scenarios where you want to partition your app up across several deployment units.

Creating a Cache Service

You can easily create a new Cache Service by going to the Windows Azure Management Portal and using the NEW -> DATA SERVICES -> CACHE option:

image

In the screenshot above, we specified that we wanted to create a new Premium cache of 5 GB named “scottgucache” in the “North Europe” region. Once we click the “Create a New Cache” button it will take about a few minutes to provision:

image

Once provisioned, the cache will show up in the Windows Azure Management Portal just like all of the other Windows Azure services (Web Sites, VMs, Databases, Storage Accounts, etc) within our subscription.  We can click the DASHBOARD tab to see more details about it:

image

We can use the cache as-is (it comes with smart defaults and doesn’t require changes to get started).  Or we can also optionally click the CONFIGURE tab to manage custom settings - like creating named cache partitions and configuring expiration behavior, evicition policy, availability settings (which means a cached item will be saved across multiple VM instances within the cache service so that they will survive even if a server crashes), and notification settings (which means our cache can call back our app when an item it updated or expired):

image

Once you make a change to one of these settings just click the “Save” button and it will be applied immediately (no need to redeploy).

Using the Cache

Now that we have created a Cache Service, let’s use it from within an application. 

To access the Cache Service from within an app, we’ll need to retrieve the endpoint URL for the Cache Service and retrieve an access key that allows us to securely access it.  We can do both of these by navigating to the DASHBOARD view of our Cache Service within the Windows Azure Management Portal:

image

The endpoint URL can be found in the “quick glance” view of the service, and we can retrieve the API key for the service by clicking the “Manage Keys” button:

image

Once we have saved the endpoint URL and access key from the portal, we’ll update our applications to use them.

Using the Cache Service Programmatically from within a .NET application

Using the Cache Service within a .NET or ASP.NET applications is easy.  Simply right-click on your project within Visual Studio, choose the “Manage NuGet Packages” context menu, search the NuGet online gallery for the “Windows Azure Caching” NuGet package, and then add it to your application:

image

After you have installed the NuGet Windows Azure Caching package, open up your web.config/app.config file and replace the cache Service EndPoint URL and access key in the dataCacheClient section of your application’s config file:

image

Once you do this, you can now programmatically put and get things from the Cache Service using a .NET Cache API with code like below:

image

The objects we programmatically add to the cache will be automatically persisted within the Cache Service and can then be shared across any number of VMs, Web Sites, Mobile Services and Cloud Services that are using the same Cache Service instance.  Because the cache is so fast (retrievals take on average about 1ms end-to-end across the wire and back) and because it can save 100s of GBs of content in-memory, you’ll find that it can dramatically improve the scalability, performance and availability of your solutions.  Visit our documentation center to learn more about the Windows Azure Caching APIs.

Enabling ASP.NET Session State across a Web Farm using the Cache Service

The new Windows Azure Cache Service also comes with a supported ASP.NET Session State Provider that enables you to easily use the Cache Service to store ASP.NET Session State.  This enables you to deploy your ASP.NET applications across any number of servers and have a customer’s session state be available on any of them regardless of which web server the customer happened to hit last in the web farm.

Enabling the ASP.NET Session State Cache Provider is really easy.  Simply add the below configuration to your web.config file:

image

Once enabled your customers can hit any web server within your application’s web farm and the session state will be available.  Visit our documentation center to learn more about the ASP.NET session state provider as well as the Output caching provider that we also support for ASP.NET.

Monitoring and Scaling the Cache

Once your Cache Service is deployed, you can track the activity and usage of the cache by going to its MONITOR tab in the Windows Azure Management Portal. You can get useful information like bandwidth used, cache miss percentage, memory used, read requests/sec, write requests/sec etc. so that you can make scaling decisions based on your real-world traffic patterns:

image

You can also customize the monitoring page to see other metrics of interest instead of or in addition to the default ones.  Clicking the “Add Metrics” button above provides an easy UI to configure this:

image

If you need to scale your cache due to increased traffic to your application, you can go to the SCALE tab and easily change the cache offering or cache size depending on your requirements.  For this example we had initially created a 5GB Premium Cache.  If we wanted to scale it up we could simply expand the slider below to be 140GB and then click the “Save” button.  This will dynamically scale our cache without it losing any of the existing data already persisted within it:

image

This makes it really easy to scale out your cache if your application load increases, or reduce your cache size if you find your application doesn’t need as much memory and you want to save costs.

Learning More

The new Windows Azure Cache Service enables you to really super-charge your Windows Azure applications.  It provides a dedicated Cache that you can use from all of your Windows Azure applications – regardless of whether they are implemented within Virtual Machines or as Windows Azure Web Sites, Mobile Services, or Cloud Services.  You’ll find that it can help really speed up your applications, improve your app scalability, and make your apps even more robust.

Review our Cache Service Documentation to learn more about the service.  Visit here to learn more about more the details about the various cache offering sizes and pricing.  And then use the Windows Azure Management Portal to try out the Windows Azure Cache Service today.

AutoScale: Schedule Updates for Web Sites + VMs, Weekend Schedules, AutoScale History

Three weeks ago we released scheduled AutoScale support for Cloud Services. Today, we are adding scheduled AutoScale support to Web sites and Virtual Machines as well, and we are also introducing support for setting up different time schedule rules depending on whether it is a weekday or weekend.

Time Scheduled AutoScale Support for Web Sites and Virtual Machines

Just like for Cloud Services, you can now go to the Scale tab for a Virtual Machines or a Web site, and you’ll see a new button to Set up schedule times:

image

Scheduled AutoScale works the same way now for Web Sites and Virtual Machines as for Cloud Services. You can still choose to scale the same way at all times (by selecting No scheduled times), but you can now click the “Set up schedule times” dialog to setup scale rules that run differently depending on the time of day:

image

Once you define the start and stop of the day using the dialog above, you can then go back to the main scale tab and setup different rules for each time segment.  For example, below I’ve setup rules so that during Week Days we’ll have between 2 and 5 small VMs running for our Web Site.  I want AutoScale to scale-up/down the exact number depending on the CPU percentage of the VMs:

image

On Week Nights, though, I don’t want to have as many VMs running, so I’ll configure it to AutoScale only between 1 and 3 VMs.  All I need to do to do this is to change the drop down from “Week Day” to “Week Night” and then edit a different set of rules and hit Save:

image

This makes it really easy to setup different policies and rules to use depending on the time of day – which can both improve your performance during peak times and save you more money during off-peak times.

AutoScale History

Previously, we supported an instance count graph on the scale tab so you can see the history of actions for your service. With today’s release we’ve improved this graph to now show the sum of CPU usage across all of your instances:

image

This means that if you have one instance, the sum of the CPU can go from 0 to 1, but if you have three instances, it can go from 0 to 3. You can use this to get a sense of the total load across your entire role, and to see how well AutosSale is performing.

Finally, we’ve also improved the Operation Log entry for AutoscaleAction: it now shows you the exact Schedule that was used to scale your service, including the settings that were in effect during that specific scale action (it’s in the section called ActiveAutoscaleProfile):

image

Web Sites: Web Server Logging to Storage Accounts

With today’s release you can now configure Windows Azure Web Sites to write HTTP logs directly to a Windows Azure Storage Account.  This makes it really easy to persist your HTTP logs as text blobs that you can store indefinitely (since storage accounts can maintain huge amounts of data) and which you can also use to later perform rich data mining/analysis on them. 

Storing HTTP Log Files as Blobs in Windows Azure Storage

To enable HTTP logs to be written directly to blob storage, navigate to a Web Site using the Windows Azure Management Portal and click the CONFIGURE tab.  Then navigate to the SITE DIAGNOSTICS section.  Starting today, when you turn “Web Server Logging” ON, you can choose to store your logs either on the file system or in a storage account (support for storage accounts is new as of today):

image

Logging to a Storage Account

When you choose to keep your web server logs in a storage account, you can specify both the storage account and the blob container that you would like to use by clicking on the green manage storage button.  This brings up a dialog that you can use to configure both:

image

By default, logs stored within a storage account are never deleted. You can override this by selecting the Set Retention checkbox in the site diagnostics section of the configure tab.  You can use this to instead specify the number of days to keep the logs, after which they will be automatically deleted:

image

Once you’ve finished configuring how you want the logs to be persisted, and hit save within the portal to commit the settings, Windows Azure Web Sites will begin to automatically upload HTTP log data to the blob container in the storage account you’ve specified.  The logs are continuously uploaded to the blob account – so you’ll quickly see the log files appear and then grow as traffic hits the web site. 

Analysis of the Logs

The HTTP log files are persisted in a blob container using a naming scheme that makes it easy to identify which log file correlates to which activity.  The log format name scheme is:

[sitename]/[year]/[month]/[day]/[hour]/[VMinstancename].log

The HTTP logs themselves are plain text files that store many different settings in a standard HTTP log file format:

image

You can easily download the log files using a variety of tools (Visual Studio Server Explorer, 3rd Party Storage Tools, etc) as well as programmatically write scripts or apps to download and save them on a machine.  Because the content of the files are in a standard HTTP log format you can then use a variety of tools (both free and commercial) to parse and analyze their content.

For more advanced scenarios, you can also now spin up your own Hadoop cluster using the Windows Azure HDInsight service.  HDInsight enables you to easily spin up, as well as quickly tear down, Hadoop clusters on Windows Azure that you can use to perform MapReduce and analytics jobs with.  Because HDInsight natively supports Windows Azure Blob Storage, you can now use HDInsight to perform custom MapReduce jobs on top of your Web Site Log Files stored there.  This provides an even richer way to understand and analyze your site traffic and obtain rich insights from it.

Operation Logs: Richer Filtering

Today’s release adds some improvements to the Windows Azure OPERATION LOGS feature (which you can now access in the Windows Azure Portal within the MANAGEMENT SERVICES section of the portal).  We now support filtering based on several additional fields: STATUS, TYPE and SERVICE NAME. This is in addition to the two filters we already support – filter by SUBSCRIPTION and TIME.

image

This makes it even easier to filter to the specific log item you are looking for quickly.

Summary

Today’s release includes a bunch of great features that enable you to build even better cloud solutions.  If you don’t already have a Windows Azure account, you can sign-up for a free trial and start using all of the above features today.  Then visit the Windows Azure Developer Center to learn more about how to build apps with it.

Hope this helps,

Scott

P.S. In addition to blogging, I am also now using Twitter for quick updates and to share links. Follow me at: twitter.com/scottgu

40 Comments

  • Wouldn't the price per GB of caching be lot better if you were using SSDs instead of RAM? Network latency is going to be the dominant performance limiter, so it's not like the slight reduction in IOPs is going to make a difference...

  • The new cache service sounds awesome. Congrats! Two quick questions I'm sure you're expecting:

    1 ) When do you expect it to be out of preview?

    2 ) What kind of pricing model are you anticipating? I inferred from this post that it would be a cost per GB of cache memory, with no separate per-transaction costs. Is that correct? That would be nice since it would mean a very predictable cost.

    Thanks!

  • I've been waiting for a good replacement for the retiring "Shared Caching Service".
    But what's up with only providing HA for premium tier with 5GB and $200/month is required?

    I want to have HA for a 128MB cache as well and pay around $45/month like the old "Shared Caching Service".
    Not providing HA before you're in the premium tier at 5GB misses the whole elasticity that the could should be all about, no?

    I guess I'm not the only one with smaller apps that still demands high availability no matter what.
    I don't want to be rude or anything, but: Any cloud service that isn't highly available is bullshit. End of story.

  • Autoscaling for a VM? How does that work?
    I can see the autoscaling for WebSites in the management portal, just not for VM's

  • Is memcached supported out of the box (or at all)? Thanks!

  • These are awesome! The cache system is going to become an amazingly useful product.

    I can't try them though as my Microsoft Account got deleted due to a bug in Live Domains. Can anyone help me?!?! I can't logon to ANY Microsoft service or even my phone. I have a paid support account but no one knows how to help me and keeps sending me back to the customer service line! I'm also willing to pay more to talk to someone who can help resolve the situation.

    If anyone can help please let me know who to send an e-mail to (thankfully my Office 365 account still works) or please contact me at my e-mail address via the spam stopper since I'm posting on a public forum: mshelp.20.nospameh@spamgourmet.com

  • It appeared in the portal, create an availability set and you are good to go

  • Scott, these are great improvements. Same as the previous ones.
    However, Azure should really go back to the basics with Virtual Machines. We need the ability to change the size of the disks (enlarge or shrink). Take for example VMs that were created during preview with a OS disk of only 30GB. Is this something in the pipeline?

    Thanks.
    Jose

  • These changes to caching are huge! Thank you, thank you, thank you!

  • @Ryan,

    >>>>>> Wouldn't the price per GB of caching be lot better if you were using SSDs instead of RAM? Network latency is going to be the dominant performance limiter, so it's not like the slight reduction in IOPs is going to make a difference...

    One of the benefits of a distributed cache is that it can span multiple servers (for availability) and can be accessed from multiple app machines (enabling you to share the data across multiple apps/machines). This enables you to use the cache across your application.

    So while you might want to use SSD for persistence of non-hot items in the cache, you'd probably still want to be able to use it across multiple machines.

    Hope this helps,

    Scott

  • @Steve,

    >>>>> The new cache service sounds awesome. Congrats! Two quick questions I'm sure you're expecting:

    >>>>> 1 ) When do you expect it to be out of preview?

    We don't have an ETA on this yet - we will be watching the preview closely to see how it goes and mark it GA once we think it is done

    >>>>> 2 ) What kind of pricing model are you anticipating? I inferred from this post that it would be a cost per GB of cache memory, with no separate per-transaction costs. Is that correct? That would be nice since it would mean a very predictable cost.

    Correct - there are no per-transaction costs. Instead you pay by cache size. Details here: http://www.windowsazure.com/en-us/pricing/details/cache/

    Hope this helps,

    Scott

  • @Jason,

    >>>> Is memcached supported out of the box (or at all)? Thanks!

    It isn't yet enabled with today's preview but we have plans to enable it with a future update.

    Hope this helps,

    Scott

  • @ScottGu,

    >>>>@Jason,

    >>>>>>>> Is memcached supported out of the box (or at all)? Thanks!

    >>>>It isn't yet enabled with today's preview but we have plans to enable it with a future update.

    Memcached might not be enabled, but existing Memcache applications can use Cache Service without any code changes - http://msdn.microsoft.com/en-us/library/windowsazure/dn386122.aspx

    Migrating Memcache applications to Cache Service is a snap! This is super neat too. :)

    >>>>Hope this helps,

    >>>>Scott

  • Hi Scott,
    Quick question - if I want to simulate the new caching service while developing locally in the emulator, is it possible? I know with, for example, service bus, that I have to point to an actual Azure service bus instance whilst developing locally. Is it the same for the caching service, or can I point it at a local caching emulator while developing locally and then update the connection string when deploying to Azure?
    Thanks,
    Phil

  • Will you release it for standalone usage and not just Azure? We would deploy it to our internal Windows servers. Don't plan to use public cloud services.

  • Scott Hanselman mentioned few weeks ago, that an Extra Small instance size is coming for Standard Mode for Web Sites.

    Any update on when can we use this?

    Thanks/

  • What are the advantage/disadvantages of the new Cache Services vs the InRole Cache?

  • This looks like some more great features. The one thing that autoscale seems to be lacking is the ability to change the instance size as part of the schedule, for instance, nights and weekends are lighter traffic for us, and we scale down during those times and scale up during the day. While we can manage this with scripts and a scheduler it would be nice to integrate this so we can get the full picture of what is happening in the auto scale interface.

  • If I'm reading this and product site, it implies that the shared cache used as "leftovers" from web/worker roles is going away, yes? That's a huge disappointment. There was *always* RAM to spare on those VM's, and it was great to use it for free across all of your instances. This is not an improvement.

  • This page (http://www.windowsazure.com/en-us/manage/services/web-sites/output-caching/) says "It is important to note that page output caching is not supported for ASP.NET MVC applications." Is there an ETA on when this will be available for ASP.NET MVC?

  • I'm not an expert but I guess I can answer a few of the questions.
    @Jeff... no it the OLD dedicated cache, that is going away. (the dedicated cache that was not ported from the Previous Silverlight portal). The In Role cache that was introduced last year is lives on ;-) The problem is that that cache can only be used from Cloud Service.

    @Craig... the only advantage with the InRole Cache is that it doesn’t cost you anything extra, if you have Spare Ram. Also is coupled to you deployment slot (production/staging) which may or may not be good thing.

    @HS... MS already has a caching solution for Windows (part of AppFabric), which used almost the same API: http://en.wikipedia.org/wiki/Velocity_(memory_cache)

    Scott... love the new additions. However the Portal is cramping up and the icons are not always intuitive... a nice little UI tweak would be to hide all services with zero units. E.g. we don't used "Media Services, SQL Reporting, Networks, Traffic manager, Active Directory etc." - Why not hide them, and have a "show all" option instead.

  • Just wondering if I'm missing something, how would you justify $400 for 5GB (non preview pricing) over $358 for a 14GB Linux VM running Memcached?

  • Great to see advancements to the caching structure however one thing that has limited me usages with it is the ability to increase size of items that the server allows. It's a simple web.config change for the client application but you still get ERRCA0016 errors when trying to add items greater than the default size

  • Very great features! Congrats and keep coding ;)

  • @Jeff: I believe that what you're referring to is called the In-Role cache and that's staying. The Shared Caching Service was the thing that _only_ provided a cache.

    http://www.windowsazure.com/en-us/pricing/details/cache/ is where I'm basing my information on.

  • Will this cache provider, specifically the one that allows distributed session state be available for on premises Windows Server 2012 R2 servers? If so what is the product called?

  • it seems there is no data transfer cost for cache usage, is this true for data transfer outside data center as well.
    In that case we can use cache as a portal for data transfer

  • >>>>What are the advantage/disadvantages of the new Cache Services vs the InRole Cache?

    Craig, check this out: http://msdn.microsoft.com/en-us/library/windowsazure/dn386094.aspx/#sectionSection0

  • So confused. The Azure Cache page not only says that Memcache support exists, but that it is supported on the wire. But here I read that it's not supported, and other places I read it still requires the shim. Besides, I have yet to see any Memcache implementation that supports passing the auth key.

    Is there any way at present to use this new Azure Cache from PHP?

  • @Hans,

    >>>>> I've been waiting for a good replacement for the retiring "Shared Caching Service". But what's up with only providing HA for premium tier with 5GB and $200/month is required? I want to have HA for a 128MB cache as well and pay around $45/month like the old "Shared Caching Service". Not providing HA before you're in the premium tier at 5GB misses the whole elasticity that the could should be all about, no? I guess I'm not the only one with smaller apps that still demands high availability no matter what. I don't want to be rude or anything, but: Any cloud service that isn't highly available is bullshit. End of story.

    Hi Hans,

    I think you might be confusing two things with HA:

    1) Whether the cache service itself is HA (meaning multi-node and the service itself can survive server failures)
    2) Whether the data in the cache can be saved HA (meaning cached data is replicated and can survive server failures)

    The old shared cache service supported #1 but didn't support #2 (there was no option to enable that).

    The new dedicated cache service supports #1 in all configurations (even the lowest/cheapest option). It has the added benefit of now support #2 as well - but only with the premium tier.

    Hope this helps,

    Scott

  • @Erik,

    >>>>>> Autoscaling for a VM? How does that work?

    AutoScaling for VMs occurs when you have multiple VMs in an availability set and you can stop/start them as needed (with no billing when they are off).

    Hope this helps,

    Scott

  • @Andy,

    >>>>>> I can't try them though as my Microsoft Account got deleted due to a bug in Live Domains. Can anyone help me?!?! I can't logon to ANY Microsoft service or even my phone. I have a paid support account but no one knows how to help me and keeps sending me back to the customer service line! I'm also willing to pay more to talk to someone who can help resolve the situation.

    Sorry you are having problems with LiveID - want to email me (scottgu@microsoft.com) and we can help?

    Thanks,

    Scott

  • @Jose,

    >>>>>> However, Azure should really go back to the basics with Virtual Machines. We need the ability to change the size of the disks (enlarge or shrink). Take for example VMs that were created during preview with a OS disk of only 30GB. Is this something in the pipeline?

    Stay tuned - we have some more VM improvements coming soon.

    Hope this helps,

    Scott

  • @phil.lee,

    >>>>>> Quick question - if I want to simulate the new caching service while developing locally in the emulator, is it possible? I know with, for example, service bus, that I have to point to an actual Azure service bus instance whilst developing locally. Is it the same for the caching service, or can I point it at a local caching emulator while developing locally and then update the connection string when deploying to Azure?

    We don't have a local cache emulator yet for the new cache service - that is coming in the future. You can point your local app at the cache in Azure though and use that for dev/test.

    Hope this helps,

    Scott

  • @HS,

    >>>>>> Will you release it for standalone usage and not just Azure? We would deploy it to our internal Windows servers. Don't plan to use public cloud services.

    We have the AppFabric Cache Server available today to download. That supports the same programming model as the cache service.

    Hope this helps,

    Scott

  • @Boris,

    >>>>> Scott Hanselman mentioned few weeks ago, that an Extra Small instance size is coming for Standard Mode for Web Sites. Any update on when can we use this?

    No ETA just yet but we are working on it.

    Hope this helps,

    Scott

  • @Jeff,

    >>>>>> If I'm reading this and product site, it implies that the shared cache used as "leftovers" from web/worker roles is going away, yes? That's a huge disappointment. There was *always* RAM to spare on those VM's, and it was great to use it for free across all of your instances. This is not an improvement.

    No - the in-role cache deployment is still supported going forward. No change to that at all (so don't worry :)

    What is going away is our old shared cache service. This is a service we didn't expose in the new HTML admin portal so a lot of people don't know what it is. It is similar to the new cache service in that it was a service (as opposed to something you needed to install). but it was multi-tenent and enforced throttling behavior which a lot of customers didn't like. It also didn't support all the features of the new dedicated cache service launched this week. That is why we are deprecating it in favor of this new service which is a super-set of functionality.

    Hope this helps,

    Scott

  • Hi Scott,

    Firstly, thanks for your wonderful Cloud sessions in TechEd Aus. Thinking about the cache service a bit more - I understand that behind the scenes VM are fired up to hold the cache. My question is, if a VM goes down for whatever reason, how is the cache rebuilt. For example, if I am storing large number or data rows from Sql Server, will the new VM call the database to build the cache or is there other built-in mechanisms.

    Thanks
    Shahed

  • Loved all the awesome features of the release. Developers and application powered by Azure and caches fitting into the story most of time will be the game changer ! THANKS FOR THE AWESOME PRODUCT!

  • It worked when I first tried it. but since weekend, I got filenotfound error on "new DataCache()", now I get errors like

    Microsoft.ApplicationServer.Caching.DataCacheException: ErrorCode:SubStatus:There is a temporary failure. Please retry later. (One or more specified cache servers are unavailable, which could be caused by busy network or servers. For on-premises cache clusters, also verify the following conditions. Ensure that security permission has been granted for this client account, and check that the AppFabric Caching Service is allowed through the firewall on all cache hosts. Also the MaxBufferSize on the server must be greater than or equal to the serialized object size sent from the client.)

Comments have been disabled for this content.