我在asp.net商店工作，今天我听说我们服务器上的瓶颈是CPU。我一直认为webapps往往是CPU之前的I / O和网络绑定。这是一个ASP.net/IIS的事情吗？这是我们的代码吗？或者我对整件事情完全错了？
此外，我们使用网络表单公开面对社交/商务网站。不是CPU负载是一个问题或任何东西，我们的服务器当前可以处理负载。我刚刚发现它令人惊讶，因为根据我对Web应用程序的理解，大多数时候CPU在扩展时不是问题，特别是在具有像.NET这样的快速运行时的编译语言上。
答案 0 :(得分：6)
这是你的代码。关于ASP.NET没有任何内在的CPU密集型，我实际上会打电话来质疑为了说CPU是瓶颈所做的研究，因为除非你正在计算你的Web应用程序中的第十亿个小数点的Pi，我认为没有理由占用所有CPU时间。
答案 1 :(得分：3)
这很可能是你的代码。你不能在这里明确地陈述关于ASP.Net的任何内容，它就像任何其他计算机程序一样 - 它完全取决于你的应用程序实际在做什么。
在提供网页方面没有任何内在的CPU密集型。我见过一台运行IIS的笔记本电脑每秒提供1200页请求 。虽然ASP.Net确实更加配置为“易用性”而不是最佳性能，但是要调整它以获得出色的性能并不是很难。
您可以使用Dottrace或RedGate Ants之类的探查器来查看代码减慢所有内容的位置。
答案 2 :(得分：1)
乍一看，我说“I / O密集，当然”，事实是，这取决于你的应用程序服务的内容。
在一个极端情况下，多媒体服务器当然会受I / O限制。
另一方面，提供相当纯文本的HTML页面的计算密集型站点将受CPU限制。
根据我的经验，我发现大多数网站都受I / O限制。也就是说，当购买额外的服务器时，它会增加I / O而不是CPU吞吐量。我甚至可以说，即使是我工作过的最精心设计的网站，其中有大约30台服务器，也可以通过单个处理器得到很好的服务。是我们购买的网络带宽。
答案 3 :(得分：1)
我会查看代码以查看是否存在性能问题。这个网站每天服务近100万页，似乎做得很好。在编写时，Asp.net针对可伸缩性进行了优化。
答案 4 :(得分：0)
如果你在谈论CPU密集型，它是相当相对的术语，但.NET不是，但ASP.NET非常多。 Web应用程序在每次请求中执行数千次回发并重新创建/销毁控件都非常昂贵。
以这种方式思考，在纯ASP.NET（非ajax，旧的）中计算可见性/颜色。仅在服务器上为1000个用户的html页面的每个元素的所有属性并将它们分发给客户端。不仅编写得很糟糕的ASP.NET服务器控件占用了更多的CPU，因为它们进行了太多的计算。
为了提高ASP.NET性能，应该使用更多的AJAX，或者像Flex / Silverlight这样的RIA将大大降低CPU开销，因为您可以使用客户端的CPU来进行数据可视化。
RIA客户端（Flex / Silverlight）+ ASP.NET Web服务是未来，我没有详细的统计数据可供分享，但我们差不多一年后离开ASP.NET，我们的CPU使用率已降至平均18％在基于RIA的网站之前的99％。
答案 5 :(得分：0)
如果你的硬件很慢，是的。对于大多数现代服务器，没有。在大多数情况下，数据库会对CPU产生更多的负担。
答案 6 :(得分：0)
运行探查器以查看应用程序中是否存在使用过多cpu或大量内存的区域。在服务器上使用任务管理器，看看它是否正在运行的IIS（inetinfo和w3wp）而不是其他进程。如果是IIS，请查看是否正在运行您的应用程序池。使用iisapp命令查找哪个应用程序池分配给哪个工作进程。