IIS7 ASP.NET应用程序-2个相同应用程序池中的2个相同应用程序，1个响应，1个没有响应

我有一个ASP.NET（v4.0）Web应用程序，该应用程序安装在虚拟目录（作为应用程序）中，并托管在其自己的应用程序池中。对于应用程序的每个实例（即每个客户）重复此操作。

应用程序池为集成（非经典）模式，并且LoadUserProfile设置为true。否则为默认设置。

每个实例当前都有自己的代码/配置副本，以及自己的数据文件夹（基本文件读/写）。

此应用程序的1个实例运行良好（用于比较的操作大约需要4秒钟）。其他所有实例运行缓慢（同一操作从10-25秒开始）。

如果我将较慢的实例移到“最快”的应用程序池中，该实例就会浮现。如果我将速度更快的实例移入速度较慢的应用程序池，则该实例将减慢爬网速度。

应用程序池最初是通过相同的方式手动创建的。后来，我使用powershell复制例程来确保更快的应用程序池的准确副本，并且仍然具有相同的行为。比较apppool.config文件显示，除了虚拟目录分配之外，它们是相同的。

据我所知，没有阻塞的共享资源，我通过关闭高性能应用程序池并重新启动进行了测试……慢仍然很慢，然后当我重新启动该应用程序池时（因此它已加载）最后）它仍然更快...

为了进一步解决问题，我建议在主机系统上运行Wireshark（或其他可选的数据包分析器）两个会话。我假设每个应用程序池都分配有一个唯一的IP或一个唯一的端口。

首先通过过滤快速应用程序池的IP：端口来获得基准性能。查看在“正常”情况下往返于应用程序的流量。

第二次运行时，您将需要从缓慢/无响应的应用程序池中捕获流量。如果所有网络路由等在此框内都是正确的，则您应该会看到一个方向上的重复请求，最有可能是来自其他地方的应用程序，但是如果您的应用程序向另一台服务器发出了很多请求，则您的流量可能是重在出口而不是入口。

此测试将告诉您问题是否出在应用程序内，还是与TCP / IP相关的问题导致由于通信不足/无通信导致对应用程序的请求超时。

将测试的时间戳与服务器的事件日志和tracesink日志相关联，您应该能够将问题归零。

失败请求跟踪（FRT）将是您进行跟踪的最佳工具。它将显示管道以及每个步骤完成的时间。这应该指出它是在asp.net部分内还是在IIS管道本身内。

要设置FRT，请从IIS在站点级别创建一个FRT规则，其HTTP状态范围为200-999，并确保启用FRT（这是从操作窗格中单独执行的步骤）。

然后重现该问题并查看生成的文件（％SystemDrive％\ inetpub \ logs \ FailedReqLogFiles \ w3svc {siteid}）。在Internet Explorer中打开它们。

当IIS由于没有明显原因而长时间延迟时，通常意味着它正在等待外部服务超时。当它这样做时，它将尝试另一种方法。因此，Windows或Linux中的任何事物都是如此。在这种情况下，对我而言，第一个可疑之处始终是网络名称解析配置。直到证明自己是无辜的，才是有罪的。

可以在一个用户点击重复站点之一的情况下重新创建它吗？当您重新创建10到20秒的响应时间时，最好知道CPU和磁盘在做什么。如果在10到20秒内似乎运行不多，则应检查绑定名称和绑定名称的名称解析。如果CPU或磁盘磨损了，那么您将需要弄清楚哪个进程工作太辛苦以及为什么。

请发布您的发现，我很好奇。

PS我还将检查名称解析并访问可能正在使用的任何身份验证服务。例如，如果需要咨询域服务器，请确保列表中的第一台DNS服务器是该域的DNS服务器。

这不是解决方案，但我们将朝着这一目标努力。

1. 在维护时间内运行IISRESET或杀死属于无响应应用程序池的W3WP

2. 启动应用程序

3. 没有响应时，获取属于慢速应用程序池的W3WP转储文件。使用流程浏览器或任务管理器创建转储文件

4. 从C：\ Windows \ Microsoft.NET \ Framework64 \ v4.0.XXXXX下获取mscordacwks.dll和mscorwks.dll

5. 将这些文件压缩并上传到我可以下载的位置。