我有一个安装在虚拟目录(作为应用程序)的ASP.NET(v4.0)Web应用程序,并托管在它自己的应用程序池中.
对于app的每个实例(即每个客户)重复这一过程.
对于app的每个实例(即每个客户)重复这一过程.
应用程序池是集成(非经典)模式,LoadUserProfile设置为true.否则,默认设置.
每个实例当前都有自己的代码/配置副本,它有自己的数据文件夹(基本文件读/写).
这个应用程序的1个实例运行良好(用于比较的操作需要约4秒).
每个其他实例运行缓慢(对于相同的操作,从10-25秒开始).
如果我将较慢的实例移动到“最快”的应用程序池中,该实例将会生动.
如果我将较快的实例移动到较慢的应用程序池中,该实例会慢慢爬行.
应用程序池最初以相同的方式创建 – 手动创建.
我后来使用了powershell复制例程来确保更快的应用程序池的精确副本,并且仍然是相同的行为.比较apppool.config文件显示它们是相同的,禁止虚拟目录分配.
据我所知,没有共享资源被阻止,我通过关闭高性能应用程序池并重新启动来测试…慢速仍然很慢,然后当我重新启动该应用程序池时(因此它已加载)最后)它仍然更快……
为了进一步隔离问题,我建议在主机系统上运行Wireshark(或其他数据包分析器),进行两次会话.假设我正在做的是每个应用程序池都分配了一个唯一的IP或一个唯一的端口.
原文链接：https://www.f2er.com/windows/370582.html首先通过过滤快速应用程序池的IP：端口来获得基准性能.在“正常”条件下查看应用程序的流量和来自应用程序的流量.
第二次运行时,您需要从缓慢/无响应的应用程序池中捕获流量.如果所有网络路由都是正确的,你应该看到一个方向上的重复请求,最有可能是来自其他地方的应用程序,但如果你的应用程序是对另一个服务器发出大量请求的东西,那么你的流量可能是在出口而不是入口处沉重.
此测试将告诉您问题是否在应用程序内,或者是否与TCP / IP相关的问题导致应用程序因低通/无通信而超时.
将测试的时间戳与服务器的事件日志和(如果适用)traceink日志相关联,您应该能够将问题归零.
