性能计数器的性能受到什么影响？
当考虑使用性能计数器作为我公司基于.NET的网站时，我想知道使用它们的开销有多大。
我想让我的网站不断更新它的计数器，还是我最好只在测量时才做？
性能影响在更新中可以忽略不计。 微软的意图是，你总是写信给性能计数器。 监视（或捕获）会导致性能下降的性能计数器。 所以，只有当你使用类似perfmon的东西来捕获数据。
实际上，性能计数器对象的效果只有“当你测量的时候这样做”。
设置性能计数器的开销通常不足以担心（设置共享内存区域和一些.NET对象，以及由于CLR实际上为您执行pipe理的CLR开销）。 这里我指的是像PerformanceCounter这样的类。
注册性能计数器的开销可能会相当缓慢，但通常不是一个问题，因为它打算在安装时发生一次，因为你想改变整个机器的状态。 你做任何复制都会变得相形见绌。 这通常不是你想在运行时做的事情。 这里我指的是PerformanceCounterInstaller。
更新性能计数器的开销通常低于在共享内存上执行互锁操作的成本。 这是比正常的内存访问慢，但是处理器原语（这是如何获得包括caching在内的整个内存子系统的primefaces操作）。 一般来说这个成本是不高的担心。 这可能是正常内存操作的10倍，根据更新以及线程和CPU之间的争用情况，可能会更糟糕。 但考虑到这一点，用primefaces更新进行跨进程通信的联锁操作并不比locking更好，也没有锁。 这里我指的是PerformanceCounter.Increment和类似的方法。
读取性能计数器的开销通常是从共享内存读取的。 正如其他人所说的，你想在一个合理的时间内进行采样（就像其他采样一样），但是只要想一想PerfMon，并试着保持采样的人为规模（思考秒而不是毫秒），你可能没有任何问题。
最后，对体验的吸引力：性能计数器非常轻巧，可以在Windows中随处使用，从内核到驱动程序到用户应用程序。 微软在内部依靠它们。
build议：性能计数器的真正问题是理解（这是温和的）和一个正确的东西（看起来很容易，但经常你错了）的学习曲线。
性能计数器只是指向共享内存（也就是内存映射文件）中的4/8字节的指针，因此它们的成本与访问int / longvariables非常相似。
我已经testing了这些很多。
在旧的Compaq 1Ghz 1处理器机器上，我能够创build约10,000个计数器并远程监视它们，CPU使用率约为20％。 这些不是自定义计数器，只是检查CPU或其他。
基本上，你可以监视任何体面的新机器上的所有计数器，影响很小。
对象的实例化可能需要很长时间，几秒到几分钟。 我build议你多收集所有的计数器，否则你的应用程序将永远坐在那里创build这些对象。 不确定一旦你创build它需要这么长时间，MS做什么，但你可以做1000 1000个线程的计数器在同一时间你可以做1计数器和1线程。
我同意famoushamsandwich，但是会补充说，只要你的抽样率合理（5秒或更长），并且你监视了一组合理的计数器，那么测量的影响也是可以忽略不计的（在大多数情况下）。
我发现的事情是，这对大多数应用程序来说并不是那么慢。 我不会把一个人放在一个紧密的圈子里，或者是一秒钟几千次的东西。
其次，我发现以编程方式创build性能计数器是非常缓慢的，所以请确保您先创build它们，而不是代码。
