我有一个 ASP.NET (v4.0) Web 应用程序，它安装在虚拟目录中（作为应用程序），并托管在自己的应用程序池中。此操作针对应用程序的每个实例（即每个客户）重复。
应用程序池为集成（非经典）模式，并且 LoadUserProfile 设置为 true。否则，使用默认设置。
每个实例当前都有自己的代码/配置副本，以及自己的数据文件夹（基本文件读/写）。
此应用的一个实例运行良好（用于比较的操作需要约 4 秒）。其他所有实例运行缓慢（相同操作需要 10-25 秒）。
如果我将较慢的实例移至“最快”的应用程序池，该实例将恢复运行。如果我将较快的实例移至较慢的应用程序池，该实例将变得非常缓慢。
应用程序池最初以相同的方式创建 - 手动。后来我使用 powershell 复制例程来确保更快的应用程序池的精确副本并且仍然具有相同的行为。比较 apppool.config 文件显示它们是相同的，除了虚拟目录分配。
据我所知，没有被阻止的共享资源，并且我通过关闭高性能应用程序池并重新启动进行了测试......慢仍然很慢，然后当我重新启动该应用程序池（因此它最后加载）时它仍然更快......
答案1
为了进一步隔离问题，我建议在主机系统上运行 Wireshark（或其他数据包分析器），进行两次会话。我假设每个应用程序池都分配有一个唯一的 IP，或者一个唯一的端口。
首先通过过滤快速应用池的 IP:port 来获取基准性能。查看在“正常”条件下进出应用的流量情况。
第二次运行，您将需要捕获来自缓慢/无响应的应用程序池的流量。如果所有网络路由等都正确无误，您应该会看到一个方向的重复请求，最有可能是从其他地方发往应用程序的请求，但是如果您的应用程序向另一台服务器发出大量请求，您的流量可能在出口而不是入口处很重。
此测试将告诉您问题是否出在应用程序内部，或者是否是 TCP/IP 相关问题导致由于通信量低或无通信量而导致对应用程序的请求超时。
将测试的时间戳与服务器的事件日志和（如果适用）tracesink 日志进行关联，您应该能够集中精力解决问题。
答案2
失败请求跟踪 (FRT) 将是您追踪此问题的最佳工具。它将显示管道以及完成每个步骤所需的时间。这应该指出它是 asp.net 部分内的问题还是 IIS 管道本身的问题。
要设置 FRT，请从站点级别的 IIS 创建一个 http 状态范围为 200-999 的 FRT 规则，并确保启用 FRT（它是操作窗格中的单独步骤）。
然后重现该问题并查看生成的文件 (%SystemDrive%\inetpub\logs\FailedReqLogFiles\w3svc{siteid})。在 Internet Explorer 中打开它们。
答案3
当 IIS 长时间无缘无故地延迟时，通常意味着它正在等待外部服务超时。当它超时时，它会尝试另一种方法。就此而言，Windows 或 Linux 中的几乎所有内容都是如此。在这些情况下，我首先怀疑的是网络名称解析配置。在被证明无罪之前，它都是有罪的。
能否通过一个用户访问重复网站之一来重现这种情况？当您重现 10 到 20 秒的响应时间时，最好知道 CPU 和磁盘在做什么。如果看起来在 10-20 秒内没有发生太多事情，那么您应该检查绑定名称和绑定名称的名称解析。如果 CPU 或磁盘正在消耗大量资源，那么您需要找出哪个进程工作过度以及原因。
请发布您的发现，我很好奇。
PS 我还会检查名称解析和对可能正在使用的任何身份验证服务的访问。例如，如果需要咨询域服务器，请确保列表中的第一个 DNS 服务器是该域的 DNS 服务器。
答案4
这不是解决方案，但我们会努力实现这一目标；
运行 IISRESET（在维护时间内）或终止属于无响应应用程序池的 W3WP
启动应用程序
当应用程序没有响应时，获取属于慢速应用程序池的 W3WP 的转储文件。使用进程探索器或任务管理器创建转储文件
从 C:\Windows\Microsoft.NET\Framework64\v4.0.XXXXX 下获取 mscordacwks.dll 和 mscorwks.dll
将这些文件压缩并上传到我可以下载的地方。