高性能 ASP.NET 站点（> 1000 请求/秒）答案

【问题标题】：High Performance ASP.NET Site (> 1000 Request/Second)高性能 ASP.NET 站点（> 1000 请求/秒）
【发布时间】：2012-04-05 11:20:39
【问题描述】：

我正在编写一个高性能 ASP.NET Json API，很快 > 1000 请求/秒。我所有的逻辑和处理都是在一个 IHttpHandler 中完成的。我通过秒表类测量，处理程序在大约 0,1 - 0,5 毫秒内完成请求。

但似乎 IIS 和/或其他 HTTPHandlers（模块？）正在夺走很多性能。我能以某种方式测量吗？当配置为获得最佳性能时，请求在 IIS 中会产生多少开销？

删除所有这些 HTTPHandler 会有所帮助，还是有其他技巧可以加快速度？除了 Session 之外，我不需要太多 ASP.NET 功能集（如果它可以显着提升性能，甚至可以解决这个问题）。

【问题讨论】：

因为它是“本机”异步并且可以自托管（因此您可以避免在 IIS 中运行），看起来值得一看 ASP.NET Web API（内置到 MVC4，但也可以独立使用）。我从 Henrik 的博客 @blogs.msdn.com/b/henrikn 中学到了很多东西
FWIW，这个问题的措辞对我来说有点奇怪，因为它似乎混合了延迟/带宽（使用网络术语）。相对于有效和并发地服务它们的能力，服务特定请求的延迟似乎并不那么重要（在最终用户体验之外，但与可伸缩性正交）。 IOW，如果每个请求都需要 1000 毫秒来服务，但您一次可以服务 2000 个，那么您仍然可以接受，对吧？
不确定它将在多大程度上应用于您正在创建的 API，但如果有任何可缓存的内容，请确保这样做。如果您可以保持无状态，您可能会使用 ARR 并在需要时进行横向扩展。

【解决方案1】：

衡量 Web 服务器的性能并非易事。需要考虑的几点：

找到实际的瓶颈。这可以是内存、磁盘访问、缓存、数据库访问、网络延迟等。使用内存分析器或其他performance profiler 来找出答案。
使用WireShark 找出请求在您的计算机上的持续时间与您的代码运行的时间之间的差异。
尝试其他配置。给 ASP.NET 更多内存。升级测试系统。即，从每秒 600 个请求的 8GB / 2.5GHz 到 16GB / 3.0GHz 可以产生 6500 个请求/秒。性能增长通常不是线性的。见this document from Microsoft。
考虑添加一台额外的机器。这可以产生高达 50 甚至更高的性能升级，具体取决于您的配置方式。再次查看 MS 的文档。
检查these hints by Jon Skeet。评论线程也揭示了一些不明显的潜在瓶颈。

注意 1：了解您的工具。 ASP.NET 在自己的线程中运行每个请求。线程交换比进程交换快，但仍然需要时间。如果其他处理程序因为在请求链中而需要时间，禁用它们是有益的。

注意 2：stackoverflow 最初的附带目标之一是在 ASP.NET 中创建一个站点，该站点在最多 2 台服务器上具有出色的性能，并且每小时可以处理超过 100 万的访问者。他们设法做到了。我相信他们在上面写了一些博文，但我不记得它们在哪里。

【讨论】：

【解决方案2】：

这是一个很好的问题。我注意到，一旦您进入单毫秒的响应时间范围，ASP.NET 开销就开始变得明显。我可以证实你的观察。

我成功完成的是找出哪些 HttpModules 已注册（使用 IIS 管理器）并禁用所有我可能摆脱的。标准的 ASP.NET 管道配置了很多模块和功能。

如果您需要终极性能，您当然可以使用一个小型 HTTP 服务器库，并通过这种方式消除几乎所有开销。这会非常快。

【讨论】：

实际上，tiny 服务器可以处理比大型 HTTP 服务器更多的请求并不是一条黄金法则。相反的情况更常见。
这与大小无关。它与每个请求运行的代码量有关。我们可以从 OP 提到的延迟中看出有很多代码在运行。不仅仅是解析 HTTP 标头和使用套接字。
同意移除已启用的模块。启用失败事件跟踪（针对 100-999 响应）并查看所有调用的模块。然后删除所有不需要的模块。 - 我不同意微型服务器的想法（但我还是支持你:)）
微型服务器的想法确实是人们最后的选择。