在 C# 和 ASP.NET 中进行跟踪对性能有何影响？答案

【问题标题】：What is the performance impact of tracing in C# and ASP.NET?在 C# 和 ASP.NET 中进行跟踪对性能有何影响？
【发布时间】：2009-03-24 13:32:17
【问题描述】：

我在最近查看的一些生产登录代码中发现了这一点...

HttpContext.Current.Trace.Write(query + ": " + username + ", " + password));

...where query 是一个简短的 SQL 查询，用于获取匹配的用户。这对性能有任何影响吗？我认为它非常小。

另外，这种确切类型的跟踪的目的是什么，使用 HTTP 上下文？这些数据追踪到哪里？提前致谢！

【问题讨论】：

【解决方案1】：

是的，只要在构建期间定义了 TRACE 条件编译常量，它就会对性能产生影响。做任何事情都会产生某种影响:)

至于这是否对应用程序产生重大影响。 Trace 被设计为运行并在许多生产应用程序中运行，因此不太可能发生这种情况。只有滥用该功能才会导致明显的性能差异。

但一如既往，不要相信我，相信分析器。

【讨论】：

【解决方案2】：

我还没有 cmets 的声望点数，但我想对 Jonathan 的回答做一个简短的说明。我所看到的数字似乎表明，仅将 stringbuilder 用于少数字符串连接是没有意义的。创建 stringbuilder 对象的开销超过了连接速度的好处。

【讨论】：

【解决方案3】：

这段代码中最大的性能损失不是在跟踪中，而是在使用 + 运算符的字符串连接中。这会执行一些低效的内存操作，在性能方面可以击败 IO 操作。我会将其更改为使用类似 string.Concat 或 StringBuilder 类（或 string.Format ）之类的东西。

【讨论】：

【解决方案4】：

跟踪消息可以发送到很多不同的地方。您可以为控制台、VisualStudio 调试窗口、文件或事件日志添加（或删除）TraceListeners 等等。您甚至可以构建自己的。

此外，您可以将 Trace 配置为在为 Release 编译时不执行任何操作。

因此，使用 Trace 对性能的影响可能会有很大差异，从零到完全瘫痪您的应用程序，这取决于哪些侦听器处于活动状态。但是，大多数听众都对您期望的影响有所了解。写入文件、数据库或控制台需要大量工作，而相对于那些 I/O 绑定活动而言，Trace 不会增加那么多开销。

不过，除了性能影响之外，我对跟踪密码值的想法绝对恐惧。那是你绝对不能做的事情。

【讨论】：

【解决方案5】：

“跟踪增加了请求的额外开销，不应为已部署的应用程序启用。但是，可以保留 Trace.Write() 语句，因为在未启用跟踪时它们会被忽略。”

【讨论】：

【解决方案6】：

如果跟踪正在写入文本文件，它的成本将高于写入控制台恕我直言

【讨论】：

视情况而定。如果文件被缓冲并且仅在缓冲区已满时刷新，则平均而言，您实际上花费的时间更少。写入 GUI 控制台非常昂贵，字体渲染、抗锯齿、视口裁剪等。
其实我考虑过写控制台的成本，觉得成本会更低，但如果你这么说，那就对了……
控制台成本很高，尤其是在 Windows 上。在等待控制台使用文本时执行阻塞。现在，如果你要缓冲控制台自己写，例如使用编写器线程，您不会注意到所有阻塞（除非由于队列增长速度快于控制台消耗它而导致内存不足;-)）。

【解决方案7】：

我猜 Trace Source 在将消息转发给侦听器之前会查看其开关的 TraceLevel。因此，如果我们将开关的默认 TraceLevel 值保持为“Error”，那么跟踪开销将大大减少，因为只会将“Error”跟踪发送给侦听器。

只是一个猜测...我还没有测量任何东西。如果我这样做会更新。

2017 年更新：似乎是一种已弃用但非常方便的方式来跟踪/记录信息到浏览器/在 asp.net 应用程序中可远程访问的 .aspx 页面。

【讨论】：