我正在尝试确定一个非常长的(imho)初始启动ASP.NET应用程序的原因。
该应用程序使用各种第三方库,并且我确信可以合并许多引用,但是,我正在尝试识别(并分配责任)dll以及它们对扩展启动过程的贡献。
到目前为止,启动时间从2-5分钟不等,具体取决于盒子上其他东西的使用情况。基于网站的复杂性,我认为这是不可接受的,我需要将其减少到最大30秒的范围内。
要明确我正在寻找的性能范围,这是从第一次请求到初始Application_Start方法被击中的时间。
那么我将从哪里开始获取有关加载哪些DLL的信息,以及加载所需的时间,以便我可以尝试将成本/收益放在一起,我们需要解决/合并。
从能力的角度来看,我一直在使用JetBrains dotTrace,而且我很清楚应用程序在应用程序之后如何对应用程序进行基准测试,但看起来它不在应用程序代码之内,因此在我目前所知的范围之外。
我正在寻找的方法是如何在我的代码的第一个入口点之前了解正在发生的事情。
注意:我知道我可以在回收/升级上调用默认页面来进行初始加载,但我宁愿解决实际问题,而不是用它来书写。
注意2:硬件在功能方面有足够的扩展和分离,因此我很确定这不是问题。
答案 0 :(得分:3)
关于分析/调试启动代码的单独答案:
w3wp只是一个运行.Net代码的进程。因此,您可以使用所有用于普通.Net应用程序的分析和调试工具。
一个棘手的问题是,w3wp进程会在第一次请求应用程序时自动启动,如果您的工具在启动时不支持附加到进程,则会对调查应用程序的启动代码产生问题。
解决问题的方法是将另一个应用程序添加到同一个应用程序池中。这样,您可以通过导航到另一个应用程序来触发w3wp创建,而不是根据已经运行的进程附加/配置您的工具。当您最终触发原始应用程序时,工具将在现有的w3wp进程中看到加载。
延迟2-5分钟你可能甚至不需要探查器 - 只需按照上面建议的方式连接Visual Studio调试器,并在加载站点期间随机触发“全部断开”几次。代码的最慢部分很可能会出现在许多线程之一的堆栈上。还要注意调试输出 - 可能会给你一些线索。
您也可以使用WinDbg以类似的方式捕获所有线程的堆栈(可能比VS更轻)。
答案 1 :(得分:2)
您的DLL引用是根据需要加载的,而不是一次性加载。
Do external references slow down my ASP.NET application? (VS: Add Reference dialog)
如果启动需要2-5分钟,我会看看Application_Start中发生了什么,以及DLL加载后的行为。他们是否尝试连接到非常慢的远程服务?机器是否太小而无法正常运行(例如,运行带有大量数据的数据库以及AWS微型实例上的Web服务器等)?
由于加载时间可能不是IIS工作进程解析引用,我会转向传统的应用程序分析器(例如Jetbrains,Antz,dotTrace)来查看DLL初始化时的时间,以及Application_Start方法
答案 2 :(得分:2)
娱乐选项检查以及分析:
生产:
答案 3 :(得分:0)
尽管有大量的dll我几乎可以肯定,对于合理的应用程序来说,它不能成为问题的原因。大多数情况下,静态对象初始化导致启动缓慢。
在C#中,首次访问类型时会初始化静态变量。我建议使用sql profiler,看看在应用程序的开始时间执行的查询是什么,从那里看看初始化的对象是什么。