性能计数器 NextValue() 非常慢（1,000+ 计数器）

在我们的应用程序中，我们使用 Windows 性能计数器来存储一些应用程序指标，稍后在某些 Web 服务中检索这些指标。

我对从计数器读取值所需的时间有疑问。我已经查看了应用程序的其余部分，一切都很好，性能方面，但是从循环内的计数器（从列表或数组）读取需要花费大量时间。

示例代码：

// This triggers a read of the counter's initial value (1000ms delay following for calculated counters)
counters.ToList().ForEach(counter => counter.NextValue());

在我对上面的循环进行的测试中，1,359 个计数器的列表需要 20 秒，并且使用秒表，读取计数器值的平均时间似乎是 0-10 毫秒，或大约 80-90 毫秒。其中很多需要 0ms，最高约为 170ms，平均非零约为 80-90ms。

也许我太乐观了，但我认为读取 1,000 个数值应该只需要几毫秒。这里正在进行的处理是否比我意识到的要多？

实际上，我稍后在逻辑中还有另一个循环，它获取计算计数器的第二个值。这只会让事情变得更加糟糕。 :)

Thanks!

Update 1

我将计数器检索包裹在秒表中，结果令我感到惊讶。即使是简单的属性也可以读取.RawValue仍然需要过多的时间。据我了解，计数器的工作原理基本相同，并且检索速度应该非常快；奇怪的是，我还发现了一种模式，即网络类别的计数器需要更长的时间。

根据http://joe.blog.freemansoft.com/2014/03/windows-performance-counters.html http://joe.blog.freemansoft.com/2014/03/windows-performance-counters.html，性能计数器服务的性能甚至不应该成为考虑因素。

我已将一些秒表结果发布到以下粘贴箱：http://pastebin.com/raw.php?i=aDJk2Tru http://pastebin.com/raw.php?i=aDJk2Tru

我的代码如下：

Stopwatch t;
foreach (var c in counters)
{
    t = Stopwatch.StartNew();
    var r = c.RawValue;
    Debug.WriteLine(t.ElapsedMilliseconds.ToString("000") + " - " + c.CategoryName + ":" + c.CounterName + "(" + c.CounterType + ") = " + r);
}

正如你在粘贴中看到的，很多读取都是 0，但也有很多在 50-100ms 范围内。我真的不明白怎么会这样。当然，一个计数器值应该与其他计数器值一样快，对吧？

这是我能找到的有关柜台的信息。请原谅语法；这是从我发出的有关此问题的电子邮件中摘录的。

• 从计数器类别读取实例名称至少需要 4-5 秒的处理时间（在服务器上可能更好或更差，不确定）。这与类别中的计数器数量的变化可以忽略不计。如果您不使用实例计数器，则可以避免这种情况。
• We store all of the counters in a single category, so it’s inevitable that category will eventually end up with thousands of counters, given our situation. In my testing, the more counters in a category, the worse the performance. This seems like it should make sense, but the performance of an individual counter is affected by the number of counters currently in memory, which is an odd correlation, maybe:
  • 总共有 8 个计数器，每个计数器的读取时间约为 1-2ms
  • 总共有 256 个计数器，每个计数器的读取时间约为 15-18ms
  • 共有 512 个计数器，每个计数器的读取时间约为 30ms
  • 总共有 3,584 个计数器（读取所有计数器），每个计数器的读取时间约为 200ms
  • 系统中有 3,584 个计数器（在内存中过滤，仅读取 512 个计数器），每个计数器的读取时间为 50-90 毫秒。不知道为什么这些比前一批 512 计数器慢。
  • 我使用以下命令运行了这些测试几次System.Diagnostics.Stopwatch给他们计时。
• 值得注意的是，计数器必须读取两次，因为许多计数器是在一段时间内计算的，并呈现开始和结束读取时间之间的平均值，因此这些坏数字在现实场景中会变得更糟。

根据上面的数字，在我的机器上，较慢的一端有 512 个计数器，每个计数器大约 50 毫秒，加上实例查询和第二个计数器读取，我们看到每个请求大约需要 60 秒。这是因为我们一次只使用 512 个计数器。我已对我的计算机上的服务运行完整查询多次，并且请求始终在 60-65 秒内完成。

我当然不会根据正在评估的其他计数器的数量来假设单个计数器的这种类型的性能下降。根据我的理解，Windows 性能监视器系统应该很快，对于小型集合来说确实如此。我们的用例可能不适合，并且我们可能正在滥用系统。

Update

鉴于我们可以控制如何创建计数器，我们决定稍微改变我们的方法。我们不是创建具有许多计数器的几个类别，而是创建许多类别，每个类别具有较少的计数器（每个类别 4-8 个计数器）。这种方法使我们能够有效避免性能问题，并且计数器读取时间在0-1ms范围内。根据我们迄今为止的经验，即使有 100 个新类别，每个类别有几个计数器，也根本不会影响系统的性能。

需要注意的是，在处理大量附加计数器时，您需要解决性能计数器默认设置的内存限制。这可以通过 machine.config 或注册表项来完成。更多信息可以在这里找到：http://msdn.microsoft.com/en-us/library/ms229387(v=vs.110).aspx http://msdn.microsoft.com/en-us/library/ms229387(v=vs.110).aspx