8

トレースを使用する場合、コンパイル時に定数が定義され、実行時にデバッガーが接続されていない、リリースモードで本番ASP.NETアプリケーションSystem.Diagnosticsの「デフォルト」トレースリスナーを削除しないことで、パフォーマンスに重大な（測定可能な）影響がありますか？TRACE

明確にするために、質問は、System.Diagnosticsトレースの代替ではなく、他のトレースリスナーを使用しているアプリケーションに対する「デフォルト」トレースリスナーの追加の影響に関するものです。

デバッガーが接続されていない場合のデフォルトトレースリスナーの影響の測定値はありますか？次のようなコードから「remove」要素を除外した場合の本番環境への影響について、すでにベンチマークが行われていますか。

<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トレースとは異なります。「デフォルト」リスナーとは何ですか。他の質問は、Visual Studioで実行してデバッグUIを更新するときのデフォルトリスナーの影響に焦点を当てているという意味で、この質問は本番環境のリリースコードに焦点を当てています。

4

2 に答える 2

14

デフォルトのトレースリスナーを使用してトレースをオンのままにすると、パフォーマンスに大きな影響を与える可能性があります。

本番環境ですぐに使用できるパフォーマンストレースが必要な場合は、トレースメソッドの代わりに.NET4.5のEventSourceクラスを使用することを強くお勧めします。これは、ETWイベントソースを作成することでPerfViewと連携し、本番環境でトレース情報を出力する場合でも、ランタイムにほとんど影響を与えません。

デフォルトのリスナーをそのままにしておくと、フレームワークはOutputDebugStringを介して呼び出しをログに記録します。これは、デバッガーのないリリースビルドであっても、パフォーマンスに大きな影響を与える可能性があります。

于 2013-02-27T18:46:05.640 に答える
0

DefaultTraceListener自体は「非常に高速」です。のように、通常、最も必要な使用法を除いて、ほとんど目立ちません。ただし、Trace.UseGlobalLockと組み合わせると、負荷の高いシステムに大きな影響を与える可能性があります。

今日、私たちのシステムは過度のCPU負荷とコンテキストスイッチング（これは別の問題です）を経験していました..そして予期しないことが起こり、作業が効果的に停止するまで問題が悪化しました：

ヘビースレッドコードは、DefaultTraceListenerの「些細な」作業に対するロックを取得する必要があったため、Trace.WriteLineで12秒以上（!!）ブロックを開始しました。

UseGlobalLockは、トレースリスナーがない場合でも適用されますが、事実上、内部に何もないロックです。これに対して、多くのスレッドが既にロードされているシステムで雪だるま式に発生する可能性のある、内部にほんの少しのロックがあります。

当面の修正は、UseGlobalLockを無効にし（これには他の副作用があります[免責事項：私の別の投稿]）、DefaultTraceListenerを削除することです。

もちろん、別のトレースリスナーが接続されている場合は、DefaultTraceListenerで費やされたすべての時間をシャドウイングする可能性があります。

于 2016-12-13T07:16:09.433 に答える