Question

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

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

...其中query是一个用于获取匹配用户的简短SQL查询。这会对性能产生什么影响吗？我认为它非常小。

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

Answer 1

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

这是否对应用程序产生重大影响。 Trace的设计运行并且在许多生产应用程序中运行的可能性极小。只有滥用此功能才能导致明显的性能差异。

但是一如既往，不要相信我，相信探究者。

Answer 2

我还没有评论的声誉点，但我想快速说明Jonathan的答案。我看到的数字似乎表明，使用stringbuilder只是少数字符串连接是没有意义的。创建stringbuilder对象的开销超过了连接速度的好处。

Answer 3

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

Answer 4

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

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

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

Answer 5

如果trace正在写入文本文件，那么写入控制台恕我直言

将花费更多

Answer 6

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

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

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

Answer 7

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