如何对正在运行的 ASP.NET 应用程序进行非侵入式分析？

Posted 2023-03-06

技术标签:

【中文标题】如何对正在运行的 ASP.NET 应用程序进行非侵入式分析？【英文标题】：How to do non-invasive profiling of a running ASP.NET application? 【发布时间】：2009-11-27 13:46:20 【问题描述】：

情况：ASP.NET 实时网站偶尔太忙了。

向代码添加完整的分析对性能的影响太大了。使用性能监视器，我们很快在与 GC 计数器配对的“所有堆中的字节数”计数器中找到了一个锯齿形数字。我们认为某些代码是罪魁祸首。

对于某些页面、库、函数或其他什么，是否有临时“注入”分析的方法或可能性？最好尽可能轻量级，因为任何额外的开销都可能导致这个脆弱的系统崩溃。我知道 .NET 不支持方法回调挂钩（这在 AOP 中很常见）。

【问题讨论】：

【参考方案1】：

一些想法：

使用自定义 Windows 性能计数器。它们非常轻量级（1% 到 2%），您不仅可以使用它们进行计数，还可以用于计时测量、查看某些操作慢于阈值的频率等。如果您使用的是 IIS 7，则可以启用失败的请求跟踪。要限制性能影响，请注意不要为太多页面启用它。这些跟踪可以提供大量详细信息，如果需要，您可以通过编程方式将更多信息注入其中。在特殊情况下使用 Windows 事件日志写入自定义详细信息。只要您不过度使用，性能影响就会很小。锯齿状内存行为的一个原因可能是在您应该调用 Dispose() 时没有调用（或将 IDisposable 对象包装在 using 语句中，这将为您调用它）；您可能需要查看您的代码以查找它。

如果对您有帮助，您可能还对我书中的性能提示感兴趣：Ultra-Fast ASP.NET。

编辑：您也可以尝试使用 .NET Memory Profiler（提供免费试用版）附加到正在运行的进程。与计数器相比，它具有相当的侵入性，但如果您需要捕获当前内存状态的快照来调试问题，那么可能没有更好的选择。

【讨论】：

感谢您的建议。我知道所有这些，事实上，我们认为可能原因的代码片段没有在 Disposable 对象周围使用 using 块。但我的直觉告诉我，这里还有其他东西（在 10 倍多的用户和相同的代码下运行了很长时间）。事件日志中没有什么奇怪的，没有奇怪的失败请求。性能计数器与我们一起全职工作（请参阅原始问题）。从您的问题来看，我认为您只是在使用现有的 Windows 性能计数器，而不是添加您自己的自定义计数器......线程/锁定问题是性能打嗝的另一个常见原因。是的，也许我的问题不是很清楚（对不起，尽量简短，不是我最好的资产）。但我应该对它们做更多的事情（自定义性能计数器），但现在不能重建，只能监控（这家商店的重要时期）。线程和锁，或其他类型的等待循环当然应该在我们的监视器上，谢谢。抱歉，我试图建议线程/锁定问题与对 IDisposables 的不当处理相结合可能解释了为什么您的代码以前运行良好，而现在不再运行了。自定义检测通常是发现此类问题的侵入性最小（有时是唯一）的方法（除了进行一些详细的代码演练）。另一种可能性是使用 .NET Memory Profiler（请参阅 memprofiler.com）——我也用该信息更新了我的答案。【参考方案2】：

是的，您可以在应用程序运行时take a memory dump 并查看它在内存中保存的内容。这应该加强或否定你的假设。

【讨论】：

调查一下，似乎确实是一条路。那篇文章缺少最有趣的东西：制作内存转储。如何？... 刚刚做了内存转储，但它重置了应用程序池，停止服务请求一段时间（在转储期间，但时间太长），实际转储为 200MB，而进程为 800MB ... 嗯... 有没有更隐蔽的东西？【参考方案3】：

我最近发布了一个类似挑战的可能解决方案：

Profiling a multi-tiered, distributed, web application (server side) 展示了一种高级方法（在 URL 级别进行分析），即：

独立于平台和语言完全无创提供您的应用程序在哪里花费大部分时间的高级图片

我们的想法是使用现有的网络日志并将它们转换成“一张图片值得一千字”的图表。

这种方法对于需要更精细细节的用例来说是不够的，但它对我个人有帮助，并且可能值得在你的案例中探索。

【讨论】：

【参考方案4】：

你能在 ASP .NET 上做this 吗？这是找出发生了什么的好方法。

【讨论】：