2008-11-14 232 views
37

当考虑使用性能计数器作为我公司的基于.NET的站点时,我想知道使用它们的开销有多大。性能计数器的性能如何?

我想让我的网站不断更新它的计数器,还是我最好只在测量时才做?

回答

20

更新中的性能影响可以忽略不计。微软的意图是你总是写信给性能计数器。监视(或捕获)会导致性能下降的性能计数器。所以,只有当你使用像perfmon这样的东西来捕获数据。

实际上,性能计数器对象仅具有“在测量时执行此操作”的效果。

+0

谢谢。你有没有可能把我指向一些数字?我很好奇他们有多好... – Boaz 2008-11-14 17:46:24

1

我发现的事情是它对于大多数应用程序来说并不慢。我不会把它放在一个紧密的循环中,或者是一秒钟被称为几千次的东西。

其次,我发现以编程方式创建性能计数器非常慢,所以请确保您在手动创建它们,而不是在代码中创建它们。

2

我同意famoushamsandwich,但会补充说,只要您的采样率合理(5秒或更长),并且您监控一组合理的计数器,那么测量的影响也可以忽略不计(在大多数情况下) 。

7

性能计数器只是指向共享内存(又名内存映射文件)中4/8字节的指针,因此它们的成本与访问int/long变量非常相似。

27

设置性能计数器的开销通常不足以担心(设置共享内存区域和一些.NET对象,以及CLR开销,因为CLR实际上为您执行管理)。在这里我指的是像PerformanceCounter这样的类。

注册性能计数器的开销可能会相当缓慢,但通常不是一个问题,因为它打算在安装时发生一次,因为您要更改机器范围的状态。与你的任何复制相比,这将会变得相形见绌。这通常不是你想在运行时做的事情。这里我指的是PerformanceCounterInstaller。

更新性能计数器的开销通常取决于在共享内存上执行互锁操作的开销。这比正常的内存访问要慢,但是是一个处理器原语(这就是它如何在包括缓存在内的整个内存子系统上进行原子操作)。一般来说,这个成本并不高。它可能是正常内存操作的10倍,可能更糟,具体取决于更新以及线程和CPU之间的争用情况。但考虑到这一点,对于使用原子更新进行跨进程通信的互锁操作,实际上是不可能的,并且不会执行任何锁定。这里我参考PerformanceCounter.Increment和类似的方法。

读取性能计数器的开销通常是从共享内存读取的。正如其他人所说的,你想在一个合理的时间内进行采样(就像任何其他采样一样),但只是想到PerfMon,并试图保持采样的人为尺度(认为秒而不是毫秒),你可能不会有任何问题。

最后,对体验的吸引力:性能计数器非常轻巧,可以在Windows中随处使用,从内核到驱动程序到用户应用程序。微软在内部依靠它们。

建议:性能计数器的真正问题是理解(这是温和的)和一个测量正确的事情(看起来很容易,但通常你弄错了)的学习曲线。

8

我测试了这些很多。

在旧的Compaq 1Ghz 1处理器机器上,我能够创建约10,000个计数器并远程监视它们,CPU占用率约为20%。这些不是自定义计数器,只是检查CPU或其他。

基本上,你可以监视全部计数器在任何像样的新机器上,影响很小。

对象的实例化可能需要很长时间,几秒到几分钟。我建议你为你收集的所有计数器多线程化,否则你的应用程序将永远坐在那里创建这些对象。不确定一旦你创建它需要这么长时间,MS会做什么,但是你可以在1000个线程的1000个线程的同时做1个计数器和1个线程。