We're running an Windows 2012R2 VM with IIS 8.5 with the purpose of serving out flat files, no ASP.NET or other dynamic content is in use. The server is configured to map 5 sites to the same IP & port filtering on FQDN and only serving HTML, JS, and CSS files across those sites. For the most part, the files are coming from virtual directories that are mapped to local folders however I am noticing the every so often files are randomly slow to load. My detailed testing has been in Chrome though I have seen similar "random" slowness in Firefox and IE.

As per configuration, most of the defaults are in place. Each site has its own application pool and those all have default configurations, and since ASP.NET isn't installed, the options are pretty basic for what is even available. After some searching I've enabled output caching in user-mode & kernel-mode set to use "file change notifications" and Compression was on by default for static and dynamic content.

The slowness comes when the sites are loading, ~54 files load at start. For various reasons most of these won't be merged, but down the road a few can be, however every so often IIS hangs on delivering one of the files. A 100KB file will deliver in a few milliseconds followed immediately by a 50KB file taking over 9 seconds. Other times all the files will load in <10ms. Note that this testing was conducted with Chrome's cache disabled for timing testing.

In general I'm a unix guy and I suspect that the answer to my woes is in using NGINX, which I personal feel is likely better suited to this task, but I believe that to be a personal bias and wanted to reach out to see if there were other possibilities that I was missing. Most places addressing performance issues with IIS seem to center around ASP.NET applications, not flat file delivery. Then again, maybe that's our problem heh.


Is this an Internet facing server, or an Intranet facing server? I wouldn't mind having a look at it myself.

Theoretically, there shouldn't be any reason why IIS is slow to serve static content - they're all routed through the static file handler, which is extremely efficient.

Some things you can try:

Ensure the websites never idle out (resulting the IIS worker process shutting down - each application pool gets it's own binary process in memory, w3wp.exe, to which the httpd hands-off once the binding is resolved - so there's some delay of 10 seconds or so to restart this process if it's shutdown) - you can do this by altering the applications pools startup setting from "on demand" to "always on".

Switch the application pool to be "no managed code" - this changes the pipeline model and ensures requests aren't run through the asp.net engine anyway.

If the server will never host any asp.net websites, you could consider killing these features (removing them). Same for dynamic compression - you could remove this if the server will never run any asp.net.

How's the Disk I/O? If IIS is monitoring the files for changes and reloading into cache, it may be that each checksum of the file is taking a while because of poor disk I/O. Are you using ESX or HyperV to vitualise? The manner in which the data store has been presented to he server (local disk vs SAN) might impact, a network stored disk will have slower I/O. This is probably a last restart though, I'm sure poor disk I/O would manifest itself in my other noticeable ways first.

Give up and dump your content in an S3 bucket and then serve it out with a Cloudfront CDN distribution. :) Just say'n.

| improve this answer | |

I was troubleshooting the same problem and seems to be some issue on IIS 8.5 when both dynamic and static compression are enabled. The same issue does not show up on IIS 10.0 (in my tests).

You could apply one any of the following workarounds:

  • Disable dynamic compression for the folder with the static files (add following to system.webServer in web.config):

     <urlCompression doDynamicCompression="false" />
  • Disable checking of hit frequency (on server level for IIS 8.5)

     %windir%\system32\inetsrv\appcmd.exe set config  -section:system.webServer/httpCompression /staticCompressionIgnoreHitFrequency:"True"  /commit:apphost
  • Tune up checking of hit frequency, using this answer.

Implement one of the qworkarounds and you'll see tremendous improvement of response/download speeds.

| improve this answer | |
  • Nice answer. Welcome to ServerFault. – Andrew Schulman Feb 7 '18 at 17:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.