Why does Web outputCache config section pointing at Azure Shared Cache slow down every request?

Question

My question is similar to this one, but my issue is with Windows Azure Shared Caching -- not the newer Windows Azure Caching.

It's really a strange issue. I have a shared azure cache set up and working on one hosted cloud service. The app is using it for both sessionState and caching/outputCache. That app has no latency issues at all. It is deployed to North Central US, as is the shared cache.

I also have a second hosted service, which is also deployed to North Central US. I have configured this second app to use the same shared cache. Here's what's odd: When I configure the <caching>/<outputCache> section in the web.config to point it to the shared cache, every single (MVC4) web request slows down to about 5-6 seconds. When I comment out this web.config section, web requests are much faster (~100 milliseconds).

It doesn't seem like a latency issue with the cache connection itself, because I am still using the same shared cache for sessionState, and that is fast. Also of note, none of the MVC4 actions are using the OutputCacheAttribute. The latency can be reproduced simply by adding the outputCache section to the web.config and redeploying.

Both apps are in the same datacenter regions, using the same vm sizes, instances, and osFamilies. The only difference between them that I can think of is that the first one (the one without latency issues) is an MVC3 app, whereas the second one is an MVC4 app.

Why would simply adding caching/outputCache config section pointed at Windows Azure Shared Cache slow down every single MVC4 request?

Update 1:

I am now able to reproduce this issue without deploying to azure. I set up my local VS / IIS Express install to use the shared cache in question for both session and outputCache. I was getting sub second responses until I changed this web.config setting:

<compilation debug="false" ... <!-- changed this from true to false

When turning off the debug hooks in the system.web section, I started getting response times of 5-6 seconds (reproduced). Could this be an issue with the bundling and minification features in MVC4? VERY odd that turning off debug compilation increases response latency ~10 fold.....

Update 2:

MiniProfiler is telling me that yes, over 4 seconds of this latency is coming from one of my @Scripts.Render("~/bundles/mybundle") in the MVC _Layout.cshtml. It appears that the outputCache setting in the web.config is affecting the release-mode rendering of bundled scripts. But WHY?

Answer 1

The optimization framework currently does not support non default outputcache providers because in the past this would cause exceptions, so in those situations the server cache is disabled and that results in the high overhead you are seeing. I think now that we've move to VirtualPathProviders, the issues we were running into with non default providers might be fixed, and we might be able to support this scenario now.

I filed a work item on our codeplex site to track this: Issue Link

Update: This shoudl be fixed in https://nuget.org/packages/Microsoft.AspNet.Web.Optimization/1.1.0-Beta1

Answer 2

I can confirm your findings. If I disable all CSS/Script bundling/minification, I do not experience the CPU spike and slowness. Clearly, this is due to something with bundling and/or minification.

This is what I have on my _Layout.cshtml. Removing it = no CPU issues. Including it will cause CPU spikes/slowness.

@Styles.Render("~/Content/css")
@Scripts.Render("~/bundles/modernizr")
@Scripts.Render("~/bundles/jquery")
@Scripts.Render("~/bundles/jqueryui")
@Scripts.Render("~/bundles/kendoui")