性能計數器的性能如何？

Question

當考慮使用性能計數器作爲我公司的基於.NET的站點時，我想知道使用它們的開銷有多大。

我想讓我的網站不斷更新它的計數器，還是我最好只在測量時才做？

Answer 1

更新中的性能影響可以忽略不計。微軟的意圖是你總是寫信給性能計數器。監視（或捕獲）會導致性能下降的性能計數器。所以，只有當你使用像perfmon這樣的東西來捕獲數據。

實際上，性能計數器對象僅具有「在測量時執行此操作」的效果。

Answer 2

我發現的事情是它對於大多數應用程序來說並不慢。我不會把它放在一個緊密的循環中，或者是一秒鐘被稱爲幾千次的東西。

其次，我發現以編程方式創建性能計數器非常慢，所以請確保您在手動創建它們，而不是在代碼中創建它們。

Answer 3

我同意famoushamsandwich，但會補充說，只要您的採樣率合理（5秒或更長），並且您監控一組合理的計數器，那麼測量的影響也可以忽略不計（在大多數情況下） 。

Answer 4

性能計數器只是指向共享內存（又名內存映射文件）中4/8字節的指針，因此它們的成本與訪問int/long變量非常相似。

Answer 5

設置性能計數器的開銷通常不足以擔心（設置共享內存區域和一些.NET對象，以及CLR開銷，因爲CLR實際上爲您執行管理）。在這裏我指的是像PerformanceCounter這樣的類。

註冊性能計數器的開銷可能會相當緩慢，但通常不是一個問題，因爲它打算在安裝時發生一次，因爲您要更改機器範圍的狀態。與你的任何複製相比，這將會變得相形見絀。這通常不是你想在運行時做的事情。這裏我指的是PerformanceCounterInstaller。

更新性能計數器的開銷通常取決於在共享內存上執行互鎖操作的開銷。這比正常的內存訪問要慢，但是是一個處理器原語（這就是它如何在包括緩存在內的整個內存子系統上進行原子操作）。一般來說，這個成本並不高。它可能是正常內存操作的10倍，可能更糟，具體取決於更新以及線程和CPU之間的爭用情況。但考慮到這一點，對於使用原子更新進行跨進程通信的互鎖操作，實際上是不可能的，並且不會執行任何鎖定。這裏我參考PerformanceCounter.Increment和類似的方法。

讀取性能計數器的開銷通常是從共享內存讀取的。正如其他人所說的，你想在一個合理的時間內進行採樣（就像任何其他採樣一樣），但只是想到PerfMon，並試圖保持採樣的人爲尺度（認爲秒而不是毫秒），你可能不會有任何問題。

最後，對體驗的吸引力：性能計數器非常輕巧，可以在Windows中隨處使用，從內核到驅動程序到用戶應用程序。微軟在內部依靠它們。

建議：性能計數器的真正問題是理解（這是溫和的）和一個測量正確的事情（看起來很容易，但通常你弄錯了）的學習曲線。

Answer 6

我測試了這些很多。

在舊的Compaq 1Ghz 1處理器機器上，我能夠創建約10,000個計數器並遠程監視它們，CPU佔用率約爲20％。這些不是自定義計數器，只是檢查CPU或其他。

基本上，你可以監視全部計數器在任何像樣的新機器上，影響很小。

對象的實例化可能需要很長時間，幾秒到幾分鐘。我建議你爲你收集的所有計數器多線程化，否則你的應用程序將永遠坐在那裏創建這些對象。不確定一旦你創建它需要這麼長時間，MS會做什麼，但是你可以在1000個線程的1000個線程的同時做1個計數器和1個線程。