服务器开发中的性能计数器
你们都同意对服务器应用程序使用性能计数器的价值。
我想知道如何使用 C# 来实现这些。
通常性能计数器具有以下属性：
- 它们是共享/全局的
- 写入需要锁以确保同步
- 读取有时也需要锁
异步更新它们是否更好？使它们异步的最佳方法是什么？
我计划使用 ThreadPool.QueueUserWorkItem() 函数。您对此有何看法？
如果我的问题看起来有点模糊，请查看 HelloWorld WCF 服务。
我还想知道以下内容：
- 在特定时期内总体受到攻击的次数
- 在特定时期内总体平均/最小/最大响应时间
如果有人知道在 .NET 或 WCF 中执行此操作的任何专门方法，请告诉我。
All of you agree with the value of using Performance Counters for server applications.
I would like to know how to implement these using C#.
Usually performance counters have the following attributes:
- They are shared/global
- Writing requires locks to ensure synchronization
- Reading sometimes requires locks too
Is it better to update them asynchronously? What is the best way to make them asynchronous?
I am planning to use the ThreadPool.QueueUserWorkItem() function. What is your opinion about this?
If my questions seem a bit vague, please look at the HelloWorld WCF service.
I also want to know the following:
- How many times it's being hit overall and within a certain period
- Average/min/max response times overall and within a certain period
If any one knows of any specialized ways to do this in .NET or WCF, please let me know.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您为此目的使用 .NET 类无需手动锁定性能计数器的增量、减量和查询 - 框架将为您完成这些操作。
如果您需要在本机代码中使用性能计数器，您仍然应该使用 InterlockedIncrement() 和朋友。
我认为异步更新性能计数器并不是一个好主意，但您的情况可能会有所不同。如果有关某些有趣情况的数据是在事后才到达的，那么它可能会被认为不太有用。在所有情况下，我都不会仅仅为了更新性能计数器而对线程池施加压力。现在，如果您无论如何都需要在线程中执行触发计数器的工作，那当然会有所不同。
一般来说，我认为性能计数器的更新并不是真正的瓶颈，而是用于更新计数器的数据的收集。
例如，.NET GC 内存性能计数器仅在 GC 实际发生时更新，因为跟踪信息（在后台）只是为了每次有机会更新计数器的成本太高（抱歉，这里没有参考，但有一些关于该特定主题的 MS 博客文章）。
最后，请注意，WCF 已经提供了相当多的计数器开箱即用，这可能已经涵盖了您现在想要的所有内容。
If you use the .NET classes for that purpose there is no need to manually lock the increment, decrement and query of a performance counter - the framework will do that for you.
If you need to use performance counters in native code you still should rather use InterlockedIncrement() and friends.
I think updating performance counters asynchronously is not such a good idea, but your milage may vary. It could be considered less usefull, if the data about some interesting situation arrives after the fact. In all cases I would not put pressure on the ThreadPool just to update a performance counter. Now, if you need to do the work that triggers the counter in a thread anyway, that would be something different of course.
Generally, I don't think that the updating of a performance counter is really a bottleneck, but rather the gathering of the data that is used to update the counter.
For example, the .NET GC Memory performance counters are only update when a GC actually happens, because tracking the information (in the background) just to update the counters everytime something chances would be too expensive (sorry, no reference here, but there are a coupble of MS blog entries about that particular subject).
Finally, be adviced that WCF already provides a rather large number of counters out of the box, which might cover all you want to now already.
您可以使用标准的 Windows 性能计数器。
可以使用 system.diagnostics.performancecounter 命名空间从 c# 访问此功能。有关 C# 示例，请参阅：
http://msdn.microsoft。 com/en-us/library/system.diagnostics.performancecounter.aspx
You could use the standard windows performance counters.
This functionality can be accessed from c# using the system.diagnostics.performancecounter namespace. For a C# example see:
http://msdn.microsoft.com/en-us/library/system.diagnostics.performancecounter.aspx