我们正在运行带有IIS 8.5的Windows 2012 R2 VM，目的是提供平面文件，不使用ASP.NET或其他dynamic内容。 服务器configuration为将5个站点映射到FQDN上相同的IP和端口筛选，并且只在这些站点上提供HTML，JS和CSS文件。 大多数情况下，文件来自映射到本地文件夹的虚拟目录，但是我注意到每个文件都是随机缓慢加载的。 我的详细testing已经在Chrome浏览器中，尽pipe我在Firefox和IE中看到了类似的“随机”缓慢。
根据configuration，大部分的默认值都已经到位。 每个站点都有自己的应用程序池，并且都有默认的configuration，而且由于没有安装ASP.NET，所以这些选项对于甚至可用的都是非常基本的。 经过一番search，我已经启用输出caching在用户模式和内核模式设置为使用“文件更改通知”和静态和dynamic内容默认打开压缩。
当网站正在加载时，速度变慢，开始加载约54个文件。 由于各种原因，大多数这些不会被合并，但在一些可能的道路上，但是每隔一段时间IIS挂起提供其中一个文件。 一个100KB的文件将在几毫秒之后传送，紧接着是一个50KB的文件，时间超过9秒。 其他时候，所有的文件都会在<10ms内加载。 请注意，此testing是在Chrome的caching禁用时间testing的情况下进行的。
总的来说，我是一个unix的家伙，我怀疑我的问题的答案是使用NGINX，我个人觉得它可能更适合这个任务，但我相信这是一个个人的偏见，并希望伸手去看看如果还有其他的可能性，我错过了。 解决IIS性能问题的大多数地方似乎围绕ASP.NET应用程序，而不是平面文件传递。 那么，也许这就是我们的问题。
这是面向互联网的服务器，还是面向内部网的服务器？ 我不介意自己看看。
从理论上讲，IIS不应该有什么理由让IIS慢速服务静态内容 – 它们都是通过静态文件处理程序路由的，这非常有效。
有些事情你可以尝试：
确保网站永远不会闲置（导致IIS工作进程closures – 每个应用程序池在内存中获取它自己的二进制进程，w3wp.exe，parsing绑定后的httpd提交 – 所以有一些延迟10秒或者如果它关机，重新启动这个过程） – 你可以通过改变应用程序池的启动设置从“on demand”到“always on”来做到这一点。
切换应用程序池为“无托pipe代码” – 这改变了pipe道模型，并确保请求不会通过asp.net引擎运行。
如果服务器永远不会托pipe任何asp.net网站，你可以考虑杀死这些function（删除它们）。 同样的dynamic压缩 – 你可以删除这个，如果服务器永远不会运行任何asp.net。
磁盘I / O如何？ 如果IIS正在监视文件以进行更改并重新加载到caching中，则可能是由于磁盘I / O较差，文件的每个校验和需要一段时间。 你在使用ESX还是HyperV？ 数据存储已呈现给服务器（本地磁盘vs SAN）的方式可能会受到影响，networking存储的磁盘将具有较慢的I / O。 这可能是最后一次重启了，但我确定可怜的磁盘I / O会首先以其他明显的方式performance出来。
放弃并将您的内容转储到S3存储桶中，然后通过Cloudfront CDN分发提供。 :)只是说'n。