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