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