在考虑将性能计数器用作我公司的基于 .NET 的站点时,我想知道使用它们的开销有多大。
我是想让我的网站不断更新它的计数器还是我最好只在我测量时才这样做?
在考虑将性能计数器用作我公司的基于 .NET 的站点时,我想知道使用它们的开销有多大。
我是想让我的网站不断更新它的计数器还是我最好只在我测量时才这样做?
设置性能计数器的开销通常不足以担心(设置共享内存区域和一些 .NET 对象,以及 CLR 开销,因为 CLR 实际上为您进行管理)。这里我指的是 PerformanceCounter 之类的类。
注册性能计数器的开销可能相当慢,但通常不是问题,因为它打算在设置时发生一次,因为您想更改机器范围的状态。你所做的任何复制都会使它相形见绌。这通常不是您想要在运行时做的事情。这里我指的是 PerformanceCounterInstaller。
更新性能计数器的开销通常归结为在共享内存上执行互锁操作的成本。这比正常的内存访问要慢,但它是一个处理器原语(这就是它如何在包括缓存在内的整个内存子系统中进行原子操作)。一般来说,这个成本并不高,不用担心。它可能是正常内存操作的 10 倍,可能更糟,具体取决于更新以及线程和 CPU 之间的争用情况。但是考虑到这一点,对于具有原子更新的跨进程通信,实际上不可能比互锁操作做得更好,并且不持有任何锁。这里我指的是 PerformanceCounter.Increment 和类似的方法。
读取性能计数器的开销通常是从共享内存中读取。正如其他人所说,您希望在合理的时间段内进行采样(就像任何其他采样一样),但只需考虑 PerfMon 并尝试将采样保持在人类规模(考虑秒而不是毫秒)并且您可能不会有任何问题。
最后,对体验的吸引力:性能计数器非常轻量级,以至于它们在 Windows 中无处不在,从内核到驱动程序再到用户应用程序。微软在内部依赖它们。
建议:性能计数器的真正问题是理解的学习曲线(适中)和衡量正确事物的曲线(看起来很容易,但你经常弄错)。
更新时对性能的影响可以忽略不计。Microsoft 的意图是您始终写入性能计数器。正是对那些性能计数器的监视(或捕获)会导致性能下降。所以,只有当你使用像 perfmon 这样的东西来捕获数据时。
实际上,性能计数器对象将仅具有“在测量时执行”的效果。
我已经测试了很多。
在一台旧的 compaq 1Ghz 1 处理器机器上,我能够创建大约 10,000 个计数器并远程监控它们大约 20% 的 CPU 使用率。这些不是自定义计数器,只是检查 CPU 或其他什么。
基本上,您可以监控任何体面的较新机器上的所有计数器,而影响很小。
对象的实例化可能需要很长时间,几秒钟到几分钟。我建议你为你收集的所有计数器多线程,否则你的应用程序将永远坐在那里创建这些对象。不确定 MS 在创建需要这么长时间后会做什么,但是您可以同时为 1000 个计数器和 1000 个线程执行此操作,同时您可以为 1 个计数器和 1 个线程执行此操作。
性能计数器只是指向共享内存(也称为内存映射文件)中 4/8 字节的指针,因此它们的成本与访问 int/long 变量的成本非常相似。
我同意着名的火腿三明治,但要补充一点,只要您的采样率合理(5 秒或更多)并且您监控一组合理的计数器,那么测量的影响也可以忽略不计(在大多数情况下)。
我发现对于大多数应用程序来说它并没有那么慢。我不会把它放在一个紧密的循环中,或者每秒调用数千次的东西。
其次,我发现以编程方式创建性能计数器非常慢,因此请确保您事先创建它们而不是在代码中。