我正在尝试确定 ASP.NET 应用程序初始启动时间过长(恕我直言)的原因。
该应用程序使用各种第三方库,并且我确信可以合并大量引用,但是,我正在尝试识别(并分配责任)dll 以及它们对扩展启动过程的贡献。
到目前为止,启动时间从 2 到 5 分钟不等,具体取决于盒子上其他东西的使用情况。基于网站的复杂性,我认为这是 Not Acceptable ,我需要将其减少到最多 30 秒的范围内。
为了明确我正在寻找的性能范围,它是从第一个请求到初始 Application_Start 方法被命中的时间。
那么我应该从哪里开始获取有关加载了哪些 DLL 以及加载它们需要多长时间的信息,以便我可以尝试将我们需要解决/整合的成本/ yield 放在一起。
从能力的角度来看,我已经使用 JetBrains dotTrace 一段时间了,我很清楚一旦我们进入应用程序后如何对应用程序进行基准测试,但它似乎在应用程序代码之外,因此在我目前所知道的范围之外。
我正在寻找的是有关如何了解在我的代码的第一个入口点之前发生的事情的方法。
注意:我知道我可以在回收/升级时调用默认页面来进行初始加载,但我宁愿解决实际问题而不是掩盖它。
注意 2:硬件在功能方面的扩展和分离绰绰有余,因此我相当确定这不是问题所在。
最佳答案
关于分析/调试启动代码的单独答案:
w3wp 只是一个运行.Net 代码的进程。因此,您可以使用将用于普通 .Net 应用程序的所有分析和调试工具。
一个棘手的问题是,w3wp 进程会在第一次请求应用程序时自动启动,如果您的工具不支持在进程启动时附加到进程,那么调查应用程序的启动代码就会出现问题。
解决它的技巧是将另一个应用程序添加到同一个应用程序池中。通过这种方式,您可以通过导航到另一个应用程序来触发 w3wp 创建,而不是针对已经运行的进程附加/配置您的工具。当您最终触发您的原始应用程序工具时,将看到加载发生在现有的 w3wp 进程中。
如果有 2-5 分钟的延迟,您甚至可能不需要探查器 - 只需按照上面建议的方式附加 Visual Studio 调试器,并在您的站点加载期间随机触发“全部中断”几次。代码中最慢的部分很有可能位于多个线程之一的堆栈中。还要注意调试输出 - 可能会为您提供一些线索。
您也可以使用 WinDbg 以类似的方式捕获所有线程的堆栈(可能比 VS 更轻便)。
关于c# - ASP.NET 启动性能分析 web,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10918631/