限制 ASP.NET 4.5 中 WebSocket 的性能因素？

Posted 2023-03-05

【中文标题】限制 ASP.NET 4.5 中 WebSocket 的性能因素？

【英文标题】：Limiting performance factors of WebSocket in ASP.NET 4.5?

【发布时间】：2012-04-16 11:27:48

【问题描述】：

MSDN 文档似乎没有很好地涵盖 ASP.net 4.5 对 html5 的支持WebSockets protocol！

这就是我要找的：

服务器/应用程序/cpu 可以支持多少实时连接？ 是否有可以设置/获取的最大传入连接数？ 无论通过套接字传输数据，每个应用程序的最佳套接字数是多少？

更新：

可以在Adobe Media Server 应用服务器上很好地配置来自闪存 RTMP 套接字（websocket 的替代方案）的请求。对应用程序内部的 ASP.net 或 IIS 8 配置的请求数量、理想时间、块大小等是否有任何类型的配置？

【问题讨论】：

我想其中大部分将是“软因素”（例如服务器/网络负载的函数），除非某处配置了“硬限制”。

你检查过 SignalR 吗？ github.com/SignalR/SignalR

@mgnoonan: 不，我没见过，不过它似乎是一个第三方.net 方库，我正在寻找的是asp.net 4.5 中对webcocket 的内置支持及其可能的局限性

@pst：所以理论上它可能是无限的？这似乎不对，因为应用程序池中的 HTTP 请求数量有限，我想知道应用程序/IIS 应用程序池中的套接字数量是否也可以限制？

ASP.NET 有许多内置限制，您在试验 WebSockets 可伸缩性时需要放宽这些限制。 SignalR 人员对此有很好的指导：github.com/SignalR/SignalR/wiki/Performance

【参考方案1】：

编辑：此答案与 .Net 4.0 或更早版本有关，其中 WebSocket 必须由您自己实现（.Net 4.5 + IIS 为您提供解决方案）。所以它只与你自己在 TCP 层之上的 WebSocket 实现有关。

.Net 可以处理的套接字数量取决于系统和提供套接字的方式。阅读：http://msdn.microsoft.com/en-us/library/windows/desktop/ms739169%28v=vs.85%29.aspx

WebSockets 实现是使用异步方式服务接收和发送数据。这使得它们非常可扩展，并且每个连接不需要大量内存。 因此，连接套接字的数量取决于每个连接和硬件的应用程序逻辑的复杂性。在大多数情况下，您将面临处理应用程序逻辑的性能问题，然后面临仅基于连接套接字的性能问题。

如果您使用的是基于原始 TCP 套接字的自己的实现，那么此信息将适用：

在单个网络设备上，您可以绑定少于 65k 的套接字。这是接受连接的侦听套接字。在通常的服务器实现中，您几乎不会使用超过几个或十分之一的套接字来接受连接。

客户端套接字的数量与您的实现和内存可以处理的一样多。

提供套接字的方法有很多种，可以让您处理更多的套接字。 几个亮点：

阻塞服务套接字的方式将延迟服务每个套接字。客户端套接字的非阻塞读取也将使用您的 CPU 来检查是否有任何可用数据。使用大量的插槽可能会非常昂贵。

每个客户端套接字的线程将使用大量内存（每个线程超过 1mb），这将允许您在每个物理系统中使用少量套接字。

最好的（恕我直言）选项之一是使用异步套接字。这允许您在单个服务器系统上拥有数千个套接字，并且通过良好的实现可以超过数万甚至数十万个套接字。

【讨论】：

Paul，请仔细阅读： > 在单个网络设备上，您可以绑定少于 65k 的套接字。这是接受连接的侦听套接字。这意味着您可以 BIND（即所谓的“服务器套接字”）。它不适用于客户端套接字。您可能拥有尽可能多的硬件、软件和操作系统。我所做的就是这么说的。所以您的评论是正确的：您可以拥有超过 65k 的客户端套接字。再次：请仔细阅读答案中写的内容。并查看什么是套接字绑定、监听，以及什么是服务器/客户端套接字。问候。

Maksims，您的回答仍然具有误导性。 OP 想要了解 ASP.NET 4.5 WebSockets 的可扩展性。可以绑定的网络套接字的数量与这个问题无关。您已获取通用 .NET 套接字编程答案并将其粘贴到 ASP.NET WebSockets 问题中。例如，您将阻塞套接字列为一个选项，但 .NET 4.5 甚至没有公开阻塞 WebSocket API。

WebSockets 不是会话的。如果实现是基于 ASP.Net WebSockets，那么它们会中继一些 IIS 设置，但它们与 HTTP 请求或类似的东西无关，因为它们不是 HTTP 请求，而是带有额外层的纯 TCP 连接顶部。

@KamyarNazeri 是的，您需要放松许多节流阀。我针对问题本身发表了评论，链接到 SignalR 的各种限制指南，这些限制可能会限制您的服务器可以接受多少 WebSocket 连接。又来了：github.com/SignalR/SignalR/wiki/Performance

另外，Maksims 关于 WebSockets 和 HTTP 之间的关系是不正确的。因为 WebSocket 连接是由 HTTP 握手启动的，所以一些适用于 HTTP 请求的 IIS 限制也适用于 WebSocket。

【参考方案2】：

致任何可能感兴趣的人：

可以对单个服务器进行超过 100k 的 WebSocket 连接 运行 ASP.NET 4.5

WebSocket 连接由 HTTP 发起 握手，因此有些IIS throttles that apply to HTTP requests 也将适用于 WebSockets。 IIS 配置中的appConcurrentRequestLimit 可用于设置每个应用程序的最大并发请求数：

<serverRuntime appConcurrentRequestLimit="250000" />

可以使用ApplicationPool's maxConcurrentRequestsPerCPU 属性设置与 ASP.net 4 Web 应用程序的最大并发连接数：

<system.web>
    <applicationPool maxConcurrentRequestsPerCPU="20000" />
</system.web>

当连接总数超过 maxConcurrentRequestsPerCPU 设置，ASP.NET 将使用队列开始限制请求。要控制队列的大小，您可以 调整machine.config requestQueueLimit:

<processModel autoConfig="false" requestQueueLimit="250000" />

应考虑以下性能计数器，同时 进行并发测试并调整最佳设置 上面详述：

NET CLR 内存#bytes in all Heaps ASP.NET\Requests Current - Queued - Rejected 处理器信息\处理器时间 TCP/IP 连接已建立 Web 服务\当前连接数 - 最大连接数 .NET CLR LocksAndThreads\ 当前逻辑线程数 - 当前物理线程数

【讨论】：

在这些参数的意义上，WebSocket 连接（即握手后）是否真的算作“并发请求”？

WebSocket（即使在空闲时）是一个持久连接，所以是的，它们确实算作并发请求

技术上是的，但是这里的语义不同。 WebSocket 连接旨在保持打开状态而不消耗资源，而 http 请求几乎总是消耗资源将运行。这就是为什么对两种类型的“请求”使用相同的限制参数没有太大意义。由于它没有意义，因此怀疑这里可能有一些需要指出的地方是合理的。

使用 HttpListener/OWIN 我已经设法在单个 Azure VM 上通过 C# 中的 SSL 通过 .NET Websockets 获得 982Mbps 的出站速度 - 所以吞吐量也相当不错。