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

如果跟蹤正在寫入文本文件，它將比寫入控制台恕我直言