与服务器建立 300 个 tcp 连接时的延迟答案

【问题标题】：Latency when establishing 300 tcp connections to server与服务器建立 300 个 tcp 连接时的延迟
【发布时间】：2021-08-07 14:00:43
【问题描述】：

我们最近集成了一些旧产品并进行了一些负载测试，其中一个产品正在使用传统技术 .Net 远程处理（使用 TCP）。通过 Process Explorer，我发现每个代理调用都会创建 1 个 TCP/IP 连接。

远程客户端和服务器都托管为窗口服务，我们有多个服务器，每个服务器最多只能同时收到 4 个请求，所以我预计限制来自远程客户端，这只是1 个远程客户端正在完成所有任务，因为客户端服务器被设计为核心中间人。

这是我迄今为止研究和测试的内容

行为有点像线程池，当活动线程多于设置的最小线程时，所有需要线程的子序列任务将被放入队列，如果线程池无法创建新线程准时释放空闲线程，但每个创建的线程将引入大约 500ms 的开销。

当它达到大约 250 个请求时开始出现延迟，所以我的问题是，当太多连接同时建立时，TCP 是否会引入一些开销，就像线程池一样？

研究了很多天，但仍然没有任何线索，任何建议或提示将不胜感激。

【问题讨论】：

最终，这似乎是一个没有实际意义的问题，因为您无法影响 .NET 远程处理的工作方式；如果您发现它没有为您提供所需的性能，我想知道是否有更好的方法是花时间研究替代方案，例如 gRPC（远程处理还有整个“安全噩梦”问题）
我们目前正在旧产品之上设计另一层 API 并将它们集成在一起，新层预计会有更高的负载。根据我这几天的研究，我同意 .net 远程处理不是在 2021 年使用的好方法，但它来自我们的遗留产品，目前我们还没有资源来重新设计所有东西，因为我们的许多遗留设计非常依赖它=/
300 个连接似乎并不令人难以置信。你有一些小的复制代码吗？恶魔可以隐藏细节，我猜在测试时也可以为你使用。
抱歉，我们没有可重现的代码，因为到目前为止在我们自己的实验室进行测试没有问题=/第二个，我们在物理服务器上运行，而我们的客户端在 VM 上运行，这可能是1 个可能的原因？

【解决方案1】：

这听起来像是original C10K 问题的一个版本（早已解决）。

当所有连接都放入某个数组中，然后定期迭代以查看需要对它们执行什么操作时，就会发生这种情况。最初的 C10K 问题由 epoll() 和各种异步 IO 诡计解决，因此。

我敢打赌，旧的 .Net 代码是针对 Socket.Select()（或需要它的东西）编译的，这就是您遇到的问题。

看看这个tale of woe。

【讨论】：