8

使用跟踪时，在发布模式下不删除生产ASP.NET 应用程序System.Diagnostics上的“默认”跟踪侦听器是否有显着（可测量的）性能影响，常量在编译时定义但在运行时没有附加调试器？TRACE

澄清一下，问题是关于“默认”跟踪侦听器对使用其他跟踪侦听器的应用程序的额外影响，而不是 System.Diagnostics 跟踪的替代方案。

当没有附加调试器时，是否有任何衡量默认跟踪侦听器影响的措施？是否已经对从代码中省略“删除”元素的生产影响进行了任何基准测试，例如：

<configuration>
<system.diagnostics>
  <trace autoflush="false" indentsize="4">
    <listeners>
      <remove name="Default" />
      <add name="myListener"  type="System.Diagnostics.TextWriterTraceListener"    initializeData="c:\myListener.log" />
    </listeners>
  </trace>
</system.diagnostics>
</configuration>

这个问题与.NET Tracing 不同：什么是“默认”侦听器？从某种意义上说，其他问题的重点是在 Visual Studio 下运行和更新调试 UI 时默认侦听器的影响，而这个问题的重点是生产环境中的发布代码。

4

2 回答 2

14

如果继续使用默认跟踪侦听器进行跟踪，则会对性能产生重大影响。

如果您想要生产就绪的性能跟踪，我强烈建议使用.NET 4.5 中的EventSource类而不是跟踪方法。这通过创建 ETW 事件源与PerfView一起使用，并且对运行时几乎没有影响，即使您在生产中输出跟踪信息也是如此。

保留默认侦听器会导致框架通过OutputDebugString记录调用。即使在没有调试器的发布版本中，这也会对性能产生重大影响。

于 2013-02-27T18:46:05.640 回答
0

DefaultTraceListener 本身“非常快”——例如，除了最随意的使用外，它通常不会引起注意。但是，与Trace.UseGlobalLock结合使用时，它会对负载较重的系统产生重大影响。

今天，我们的系统遇到了过多的 CPU 负载和上下文切换（这是另一个问题）......并且发生了一些意想不到的事情，使问题更加复杂，以至于工作有效地停止了：

重线程代码开始在 Trace.WriteLine 上阻塞超过 12 秒 (!!)，因为它必须获得对 DefaultTraceListener 中“琐碎”工作的锁定。

虽然即使没有跟踪侦听器也会应用 UseGlobalLock，但它实际上是一个内部没有任何东西的锁 - 与一个内部有一点点东西的锁相比，它可以在已经加载的具有许多线程的系统上滚雪球。

立即修复是禁用 UseGlobalLock（这有其他副作用[免责声明：我的另一个帖子]）并删除 DefaultTraceListener。

当然，如果连接了另一个跟踪侦听器，它可能会很好地掩盖在 DefaultTraceListener 中花费的所有时间。

于 2016-12-13T07:16:09.433 回答