会社の .NET ベースのサイトでパフォーマンス カウンターを使用することを検討していたとき、パフォーマンス カウンターの使用によるオーバーヘッドがどの程度大きいのか疑問に思いました。
サイトのカウンターを継続的に更新する必要がありますか、それとも測定時にのみ更新する方がよいでしょうか?
ベストアンサー1
パフォーマンス カウンターを設定するためのオーバーヘッドは、通常、心配するほど高くはありません (共有メモリ領域といくつかの .NET オブジェクトの設定、および CLR が実際に管理を行うため CLR オーバーヘッドが発生します)。ここでは、PerformanceCounter などのクラスについて言及しています。
パフォーマンス カウンターの登録のオーバーヘッドはかなり遅くなる可能性がありますが、マシン全体の状態を変更するためにセットアップ時に 1 回だけ実行されるため、通常は問題にはなりません。これは、実行するコピーに比べれば小さいものです。通常は、実行時に実行したいものではありません。ここでは、PerformanceCounterInstaller について言及しています。
パフォーマンス カウンターを更新するオーバーヘッドは、一般的に、共有メモリでインターロック操作を実行するコストに帰着します。これは通常のメモリ アクセスよりも低速ですが、プロセッサ プリミティブです (キャッシュを含むメモリ サブシステム全体でアトミック操作を実行する方法です)。通常、このコストは心配するほど高くはありません。通常のメモリ操作の 10 倍になる可能性があり、更新やスレッドと CPU 間の競合の状況によっては、さらに悪化する可能性があります。ただし、アトミック更新によるプロセス間通信でインターロック操作よりも優れた操作を行うことは文字通り不可能であり、ロックは保持されません。ここでは、PerformanceCounter.Increment および同様のメソッドを参照します。
パフォーマンス カウンターの読み取りのオーバーヘッドは、通常、共有メモリからの読み取りです。他の人が言っているように、(他のサンプリングと同様に) 適切な期間でサンプリングする必要がありますが、PerfMon を念頭に置いて、サンプリングを人間のスケール (ミリ秒ではなく秒) に保つようにすれば、おそらく問題は発生しないでしょう。
最後に、エクスペリエンスへのアピール: パフォーマンス カウンターは非常に軽量であるため、カーネルからドライバー、ユーザー アプリケーションまで、Windows のあらゆる場所で使用されます。Microsoft は社内でパフォーマンス カウンターに依存しています。
アドバイス: パフォーマンス カウンターに関する本当の問題は、理解するための学習曲線 (中程度) と、正しいものを測定する方法 (簡単そうに見えますが、間違えることが多い) です。