我们正在运行带有 IIS 8.5 的 Windows 2012R2 VM，目的是提供平面文件，不使用 ASP.NET 或其他动态内容。服务器配置为将 5 个站点映射到相同的 IP 和 FQDN 上的端口过滤，并且仅在这些站点上提供 HTML、JS 和 CSS 文件。在大多数情况下，文件来自映射到本地文件夹的虚拟目录，但我注意到文件偶尔会随机加载缓慢。我的详细测试是在 Chrome 中进行的，尽管我在 Firefox 和 IE 中也看到过类似的“随机”缓慢现象。
根据配置，大多数默认设置都已到位。每个站点都有自己的应用程序池，这些应用程序池都有默认配置，而且由于未安装 ASP.NET，因此这些选项对于可用的选项来说非常基本。经过一番搜索，我在用户模式和内核模式下启用了输出缓存，设置为使用“文件更改通知”，并且默认情况下对静态和动态内容启用压缩。
加载网站时速度会变慢，开始时大约加载 54 个文件。由于各种原因，大多数文件都不会合并，但以后可能会合并一些文件，不过 IIS 时不时会在传输某个文件时挂起。传输一个 100KB 的文件需要几毫秒，紧接着传输一个 50KB 的文件需要 9 秒以上。其他时候，所有文件将在不到 10ms 内加载完毕。请注意，此测试是在禁用 Chrome 缓存的情况下进行的，以进行时间测试。
总的来说，我是一个 Unix 爱好者，我怀疑解决我的问题的方法是使用 NGINX，我个人认为它可能更适合这项任务，但我认为这是个人偏见，我想了解一下我是否错过了其他可能性。大多数解决 IIS 性能问题的地方似乎都围绕着 ASP.NET 应用程序，而不是平面文件传输。不过，也许这是我们的问题，呵呵。
答案1
这是面向 Internet 的服务器，还是面向 Intranet 的服务器？我不介意亲自查看一下。
从理论上讲，IIS 提供静态内容的速度应该没有任何原因 - 它们都是通过静态文件处理程序路由的，这是非常高效的。
您可以尝试以下方法：
确保网站永不闲置（导致 IIS 工作进程关闭 - 每个应用程序池在内存中获取自己的二进制进程 w3wp.exe，一旦绑定得到解决，httpd 就会将其移交给该进程 - 因此如果关闭，则需要大约 10 秒的延迟才能重新启动该进程） - 您可以通过将应用程序池启动设置从“按需”更改为“始终开启”来实现此目的。
将应用程序池切换为“无托管代码” - 这会改变管道模型并确保请求不会通过 asp.net 引擎运行。
如果服务器永远不会托管任何 asp.net 网站，您可以考虑关闭这些功能（删除它们）。动态压缩也一样 - 如果服务器永远不会运行任何 asp.net，您可以删除它。
磁盘 I/O 怎么样？如果 IIS 正在监控文件的变化并重新加载到缓存中，则可能是由于磁盘 I/O 较差，文件的每个校验和都需要一段时间。您是否使用 ESX 或 HyperV 进行虚拟化？数据存储呈现给服务器的方式（本地磁盘与 SAN）可能会产生影响，网络存储磁盘的 I/O 会更慢。不过，这可能是最后一次重启，我相信较差的磁盘 I/O 会首先以其他明显的方式表现出来。
放弃并将您的内容转储到 S3 存储桶中，然后使用 Cloudfront CDN 分发提供它。:) 只是说说而已。
答案2
我正在排除同样的问题，似乎在启用动态和静态压缩时，IIS 8.5 上会出现一些问题。同样的问题不会出现在 IIS 10.0 上（在我的测试中）。
您可以应用以下任一解决方法：
禁用包含静态文件的文件夹的动态压缩（
system.webServer在中添加以下内容web.config）：<urlCompression doDynamicCompression="false" />禁用命中频率检查（在 IIS 8.5 的服务器级别）
%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /staticCompressionIgnoreHitFrequency:"True" /commit:apphost调整命中频率检查，使用这个答案。
实施其中一种 qworkarounds，您将看到响应/下载速度的显著改善。