Why does the Web outputCache configuration section pointing to the Azure shared cache slow down every request?

Question

My question is similar to this , but my problem is with Windows Azure shared caching - not the new Windows Azure caching.

This is a really weird problem. I have a common azure cache configured and working on one hosted cloud service. The application uses it for both sessionState and caching/outputCache . This application has no latency issues. It is deployed in the Northern Central USA, as is a shared cache.

I also have a second hosted service, which is also hosted in North Central USA. I configured this second application to use the same shared cache. Here's the strange thing: When I configure the <caching>/<outputCache> section of the web.config file to point it to the shared cache, each individual (MVC4) web request slows down to about 5-6 seconds. When I comment on this section of web.config, web requests are much faster (~ 100 milliseconds).

This doesn't seem to be a delay problem with the cache connection itself, because I still use the same shared cache for sessionState, and it is fast. It should also be noted that none of the MVC4 actions uses OutputCacheAttribute. The delay can be reproduced simply by adding the outputCache section to web.config and redistributing it.

Both applications are located in the same areas of the data center, using the same vm sizes, instances, and osFamilies. The only difference between them that I can think of is that the first (the one that has no lag problems) is the MVC3 application, while the second is the MVC4 application.

Why does simply adding the Cache I / O configuration section specified in the Windows Azure shared cache slow down every MVC4 request?

Update 1:

Now I can reproduce this problem without deploying to azure. I installed a local VS / IIS Express installation to use the shared cache for session and outputCache. I got secondary answers until I changed the web.config setting:

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

When disabling debug hooks in the system.web section, I started to get a response time of 5-6 seconds (playing). Could this be a problem with union and minimize functions in MVC4? It is VERY strange that disabling debug compilation increases the response delay ~ 10 times .....

Update 2:

MiniProfiler tells me that yes, more than 4 seconds of this delay comes from one of my @ Scripts.Render ("~ / bundles / mybundle") in MVC _Layout.cshtml. It looks like the outputCache parameter in the web.config file affects the rendering in batch script mode. But WHY?

Answer 1

Currently, the optimization infrastructure does not support vendors of non-standard output caches, since in the past this would throw exceptions, therefore in these situations the server cache is disabled, and this leads to the high costs that you see. Now I think that we will move on to VirtualPathProviders, the problems that we encountered with non-default providers can be fixed, and we could support this scenario now.

I registered a work item on our codeplex website to track this: Link to a problem

Update : this shoudl will be fixed at https://nuget.org/packages/Microsoft.AspNet.Web.Optimization/1.1.0-Beta1

Answer 2

I can confirm your findings. If I turn off all CSS / Script binding / minimization, I don't experience a CPU spike and slowness. Clearly, this has something to do with snapping and / or minimization.

This is what I have on my _Layout.cshtml. Removing it = CPU problems. Including this 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")