C# 和 ASP.NET 中的跟踪对性能有何影响？

Question

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

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

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

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

Answer 1

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

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

但一如既往，不要相信我，相信探查器。

Answer 2

我还没有评论的声誉点，但我想就乔纳森的回答做一个简短的陈述。 我所看到的数字似乎表明，仅将 stringbuilder 用于少数字符串连接是没有意义的。 创建字符串生成器 object 的开销超过了连接速度的好处。

Answer 3

跟踪消息可以 go 到很多不同的地方。 您可以添加（或删除）控制台的 TraceListener、VisualStudio 调试 Window、文件或事件日志等等。 你甚至可以建立自己的。

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

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

---

不过，抛开性能影响不谈，我对跟踪密码值的想法感到非常恐惧。 那是你绝对不能做的事情。

Answer 4

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

Answer 5

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

http://msdn.microsoft.com/en-us/library/ms972204.aspx

Answer 6

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

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

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

https://msdn.microsoft.com/en-IN/library/z48bew18(v=vs.71).aspx

Answer 7

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