Каков хит производительности Счетчиков производительности

Я соглашаюсь с famoushamsandwich, но добавил бы, что, пока Ваша частота дискретизации разумна (5 секунд или больше), и Вы контролируете разумный набор счетчиков, тогда влияние измерения незначительно также (в большинстве случаев).

Вещь, которую я нашел, состоит в том что не то, чтобы медленная для большинства приложений. Я не поместил бы один в жесткий цикл или что-то, что называют тысячами времен в секунду.

, Во-вторых, я нашел, что программно создание счетчиков производительности является очень медленным, поэтому удостоверьтесь, что Вы создаете их перед рукой а не в коде.

Счетчик производительности - это просто указатель на 4/8 байтов в общей памяти (также известный как файл с отображением памяти), поэтому их стоимость очень похожа на стоимость доступа к переменной int / long.

The overhead of setting up the performance counters is generally not high enough to worry about (setting up a shared memory region and some .NET objects, along with CLR overhead because the CLR actually does the management for you). Here I'm referring to classes like PerformanceCounter.

The overhead of registering the perfromance counters can be decently slow, but generally is not a concern because it is intended to happen once at setup time because you want to change machine-wide state. It will be dwarfed by any copying that you do. It's not generally something you want to do at runtime. Here I'm referring to PerformanceCounterInstaller.

The overhead of updating a performance counter generally comes down to the cost of performing an Interlocked operation on the shared memory. This is slower than normal memory access but is a processor primitive (that's how it gets atomic operations across the entire memory subsystem including caches). Generally this cost is not high to worry about. It could be 10 times a normal memory operation, potentially worse depending on the update and what contention is like across threads and CPUs. But consider this, it's literally impossible to do any better than interlocked operations for cross-process communication with atomic updates, and no locks are held. Here I refer to PerformanceCounter.Increment and similar methods.

The overhead of reading a performance counter is generally a read from shared memory. As others have said, you want to sample on a reasonable period (just like any other sampling) but just think of PerfMon and try to keep the sampling on a human scale (think seconds instead of milliseconds) and you proably won't have any problems.

Finally, an appeal to experience: Performance counters are so lightweight that they are used everywhere in Windows, from the kernel to drivers to user applications. Microsoft relies on them internally.

Advice: The real question with performance counters is the learning curve in understanding (which is moderate) and one measuring the right things (seems easy but often you get it wrong).

Я тестировал их много раз.

На старой машине compaq 1Ghz с 1 процессором я смог создать около 10 000 счетчиков и контролировать их удаленно при использовании около 20% процессора. Это не пользовательские счетчики, просто проверка CPU или что-то еще.

В принципе, вы можете контролировать все счетчики на любой приличной более новой машине с очень небольшим воздействием.

Инстанцирование объекта может занять много времени, от нескольких секунд до нескольких минут. Я советую вам сделать это многопоточным для всех счетчиков, которые вы собираете, иначе ваше приложение будет сидеть там вечно, создавая эти объекты. Не уверен, что MS делает после создания объекта, что занимает так много времени, но вы можете сделать это для 1000 счетчиков с 1000 потоками за то же время, за которое вы можете сделать это для 1 счетчика и 1 потока.