ASP.NET 检索平均 CPU 使用率

发布于 2024-09-02 08:02:01 字数 489 浏览 4 评论 0原文

昨晚我在一个网站上做了负载测试。我发现我的共享缓存之一是瓶颈。我正在使用 ReaderWriterLockSlim 来控制数据的更新。不幸的是,大约在同一时间有大约 200 个请求尝试更新数据。这也与 CPU 使用率峰值相吻合。

正在更新的数据位于 ASP.NET 缓存中。我想做的是,如果 CPU 使用率约为 75%,我想跳过缓存并访问另一台计算机上的数据库。

我的问题是我不知道创建一个新的性能计数器来检查 cpu 使用情况有多昂贵。另外,如果我想了解过去 2 或 3 秒的平均 cpu 使用情况。但是,我不能坐在那里计算 CPU 时间,因为这将比当前更新缓存所需的时间更长。

有没有简单的方法来获取平均 CPU 使用率?这有什么缺点吗?

我还在考虑总计锁定的等待计数,然后在某个阈值切换到数据库。我对这种方法的担忧是,改变硬件可能会允许更多的锁,同时对系统的压力更小。而且找到阈值的正确平衡也很麻烦,而且它没有考虑机器上的任何其他负载。但这是一种简单的方法,而且 99% 的情况下简单就是更好。

Last night I did a load test on a site. I found that one of my shared caches is a bottleneck. I'm using a ReaderWriterLockSlim to control the updates of the data. Unfortunately at one point there are ~200 requests trying to update the data at approximately the same time. This also coincided with CPU usage spikes.

The data being updated is in the ASP.NET Cache. What I'd like to do is if the CPU usage is around 75%, I'd like to just skip the cache and hit the database on another machine.

My problem is that I don't know how expensive it is to create a new performance counter to check the cpu usage. Also, if I would probably like the average cpu usage over the last 2 or 3 seconds. However, I can't sit there and calculate the cpu time as that would take longer than it's taking to update the cache currently.

Is there an easy way to get the average CPU usage? Are there any drawbacks to this?

I'm also considering totaling the wait count for the lock and then at a certain threshold switch over to the database. The concern I had with this approach would be that changing hardware might allow more locks with less of a strain on the system. And also finding the right balance for the threshold would be cumbersome and it doesn't take into account any other load on the machine. But it's a simple approach, and simple is 99% of the time better.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

高速公鹿 2024-09-09 08:02:01

Microsoft 的这篇文章介绍了调整 .Net 应用程序性能 并突出显示要收集和比较哪些计数器以确定 CPU 和 I/O 密集型应用程序。

您听起来像是想在执行过程中监视这一点,并在事情变得密集时绕过缓存。这不只是将密集处理从缓存调用转移到数据库调用吗?当然,您有缓存来避免昂贵的数据库调用。

您是否正在尝试重新填充失效的缓存?从缓存提供陈旧数据有何影响?您可以锁定重新填充功能并将过时的数据提供给其他请求,直到该过程完成。

根据上面的文章,我们在测试期间收集了以下计数器对象,这为我们提供了确定瓶颈所需的所有计数器。

  • .NET CLR 异常
  • .NET CLR 内存
  • ASP.NET 应用程序
  • ASP.NET
  • 内存
  • 分页文件
  • 处理器
  • 线程

文章中的部分 CLR 调整ASP.NET 调整 突出显示可能发生的瓶颈并建议更改配置以提高性能。我们当然对线程池设置进行了更改以获得更好的性能。

更改和检索性能计数器值可能会有所帮助通过代码访问现有的处理器计数器,但这不是我亲自尝试过的。

This article from Microsoft covers Tuning .Net Application Performance and highlights which counters to collect and compare to determine CPU and I/O bound applications.

You sound like you want to monitor this during execution and bypass your cache when things get intensive. Would this not just move the intensive processing from the cache calls to your database calls? Surely you have the cache to avoid expensive DB calls.

Are you trying to repopulate an invalidated cache? What is the affect of serving stale data from the cache? You could just lock on the re-populating function and serve stale data to other requests until the process completes.

Based on the above article, we collect the following counter objects during our tests and that gives us all the necessary counters to determine the bottlenecks.

  • .NET CLR Exceptions
  • .NET CLR Memory
  • ASP.NET Applications
  • ASP.NET
  • Memory
  • Paging File
  • Processor
  • Thread

The sections in the article for CLR Tuning and ASP.NET Tuning highlight the bottlenecks that can occur and suggest configuration changes to improve performance. We certainly made changes to the thread pool settings to get better performance.

Changing and Retrieving Performance Counter Values might help with accessing the existing Processor counter via code but this isn't something I've tried personally.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文