Azure Website slow to serve static JS/CSS but not binary

Question

I have an Azure Website/Web App that is incredibly slow to serve static JS and CSS files but seems perfectly fine serving binary.

To test the problem I uploaded two 30MB files, one big.js and the other big.rar. The JS file downloads at around 100KB/s if I'm lucky. The RAR file downloads at around 4,000KB/s. The results are extremely consistent.

I've checked in Fiddler and gzip compression is occurring in both cases. As expected, the JS file is being sent with the MIME type application/x-javascript whereas the RAR file is being served as application/octet-stream.

I am struggling to understand this - why would IIS serve one type of static content so much slower than another?

Asthenic

its downloading a 900KB js file in three minutes in my case – Drusie

Did you ever find a solution to this? I'm actually getting 10 KB/s for text files unless I specify Ranges in the requests – Skedaddle

you are not alone.... #33135491 – Cense

Do you have some extension that would process text files such as Bundle that will compress/minify js files etc? – Wedge

Answer 1

We had this issue, and was able to resolve this with the help of Azure Support Team. The issue was that the slow files would use TransferEncoding: Chuncked. They suggested that we force static compression to get around this issue.

We had to add the following to <system.webServer>:

<serverRuntime enabled="true"  frequentHitThreshold="1"  frequentHitTimePeriod="00:00:20" />

Spelt

Awesome! Worked here as well :) – Propylene

This worked for me as well. Have you noticed any performance hit (CPU or otherwise) when enabling this web.config option? – Inlaid

Thanks a lot! Faster 20X – Warthog

Nice one.. looks like a hidden gem.. But still, any drawback with having this config on? Could anybody explain a bit more? – Melba

@Melba See my answer for a full explanation :) – Vachon

Anyway I just cannot fix the web.config in production sites. If I apply the changes, IIS goes mad about the fact that <serverRuntime> is a locked section of the configuration.... thanks m$... – Thirtytwo

Answer 2

To elaborate on John Tseng's answer: (from here)

As you saw earlier, IIS 7 caches the compressed versions of static files. So, if a request arrives for a static file whose compressed version is already in the cache, it doesn’t need to be compressed again.

But what if there is no compressed version in the cache? Will IIS 7 then compress the file right away and put it in the cache? The answer is yes, but only if the file is being requested frequently. By not compressing files that are only requested infrequently, IIS 7 saves CPU usage and cache space.

By default, a file is considered to be requested frequently if it is requested two or more times per 10 seconds.

So, the reason your users are being served an uncompressed version of the javascript file is because it didn't meet the default threshold for being compressed; in other words, the javascript file was not requested 2 times within 10 seconds.

To control this, there is one attribute we must change on the <serverRuntime> element, which controls compression: frequentHitThreshold. In order for your file to be compressed when it is requested once, change your <serverRuntime> element to look like this:

<serverRuntime enabled="true" frequentHitThreshold="1" />

This will slightly impact your CPU performance if you have many javascript files that are being served and you have users quite often, but likely if you have users often enough to impact CPU from compressing these files, then they are already compressed and cached!

Vachon

Answer 3

Looks like it was an issue on IIS 8.5 and not only Azure specific.

Now App service upgrade to Windows Server 2016 looks complete and this workaround should not be needed.

Obscurantism