我有一个安装在虚拟目录（作为应用程序）的ASP.NET（v4.0）Web应用程序，并托pipe在它自己的应用程序池中。 对于应用程序的每个实例（即每个客户）重复这一点。
应用程序池是集成（非经典）模式，并且LoadUserProfile设置为true。 否则，默认设置。
每个实例当前都有它自己的代码/configuration副本，它是自己的数据文件夹（基本文件读/写）。
这个应用程序的1个实例运行良好（用于比较的操作需要约4秒）。 每个其他实例运行缓慢（从10-25秒为同一操作）。
如果我将较慢的实例移动到“最快”的应用程序池，那么这个实例就会变成现实。 如果我将更快的实例移动到速度较慢的应用程序池中，则该实例会减慢抓取速度。
应用程序池最初是以相同的方式创build的 – 手动。 后来我使用了powershell copy例程，以确保更快的应用程序池的精确副本，并仍然是相同的行为。 比较apppool.config文件显示它们是相同的，禁止虚拟目录分配。
没有共享资源正在被阻止，据我所知，我testing通过closures性能的应用程序池并重新启动…慢仍然很慢，然后当我重新启动应用程序池（所以它被加载最后）还是更快
为了进一步隔离这个问题，我build议在主机系统上运行Wireshark（或其他select的分组分析器）两个会话。 我正在做的假设是，每个应用程序池都有一个唯一的IP分配给它，或一个独特的端口。
首先通过过滤快速应用程序池的IP：端口来获得基准性能。 在“正常”条件下查看应用程序的stream量和应用程序的stream量。
第二次运行，您将需要从缓慢/无响应的应用程序池捕获stream量。 如果所有的networking路由select都是正确的，那么您应该看到一个方向的重复请求，最有可能是来自其他地方的应用程序，但是如果您的应用程序对另一台服务器提出了很多请求，那么您的stream量可能是沉重的出口而不是入口。
这个testing会告诉你，如果问题是在应用程序内，或者是由于低/无通信导致对应用程序的请求超时的TCP / IP相关的问题。
将testing的时间戳与服务器的事件日志和（如果适用的话）跟踪链接日志相关联，并且您应该能够解决问题。
失败的请求追踪（FRT）将是您追踪这件事的最佳工具。 它将显示pipe道和每个步骤完成需要多长时间。 这应该指出，它是否是在asp.net部分内的东西，或者如果它是在IISpipe道本身内的东西。
要设置FRT，请从站点级别的IIS创build一个HTTP状态范围为200-999的FRT规则，并确保启用FRT（这是与操作窗格分开的一个步骤）。
然后重现问题并查看生成的文件（％SystemDrive％\ inetpub \ logs \ FailedReqLogFiles \ w3svc {siteid}）。 在Internet Explorer中打开它们。
当IIS无故拖延很长一段时间时，通常意味着它正在等待外部服务超时。 当它这样做，然后尝试另一种方法。 对于这一点，Windows或Linux中的任何事情都是如此。 在这些情况下，我的第一个嫌疑人总是networking名称parsingconfiguration。 这是有罪的，直到certificate无辜。
这可以重新创build与一个用户打一个重复的网站？ 当您重新创build10到20秒的响应时间时，知道CPU和磁盘正在做什么是一件好事。 如果看起来在10-20秒内没有太多的事情发生，那么你应该检查绑定名称和绑定名称的名称parsing。 如果CPU或磁盘咀嚼，那么您将需要找出哪个过程工作太辛苦，为什么。
请张贴你的发现，我很好奇。
PS我也会检查名称parsing和访问任何可能正在使用的身份validation服务。 例如，如果需要咨询域名服务器，请确保列表中的第一个DNS服务器是域名的DNS服务器。
这不是解决scheme，但我们会努力的;
运行IISRESET（在维护时间内）或终止属于无响应应用程序池的W3WP
启动应用程序
在没有响应的情况下，抓取属于缓慢应用程序池的W3WP转储文件。 使用进程资源pipe理器或任务pipe理器来创build转储文件
从C：\ Windows \ Microsoft.NET \ Framework64 \ v4.0.XXXXX下载mscordacwks.dll和mscorwks.dll
邮编和上传这些文件从我可以下载的地方。