我在负载平衡器后面有一组 Java Vertx 服务器，用于处理峰值流量。一分钟它可能处理 150k r/m，下一分钟它可能处理 2mm r/m，然后又回到 150k r/m。我发现在这些高峰期间，整个队列可能会在几分钟内无响应并断开连接，而任何一台机器上的 cpu 和 mem 压力几乎没有达到 50% 的利用率。
为了测试究竟是什么导致了中断，我设置了一个测试服务器，它与我的生产队列中的一个服务器的规格相匹配，以查看在它发出之前我可以投入多少。我的测试涉及使用其他 10 台机器，每台机器打开 500 个到服务器的 https 连接，并发送 1mm 请求，每个请求有效负载约 2kb。这总共打开了 5k 个并发连接，发送了总共 10mm 的请求，用于大约 20gb 的数据传输。
一旦连接打开，我每分钟可以发出大约 70 万个请求。我只是通过向健康端点发出请求并记录响应时间来监控服务器的可用性。响应时间快，几十毫秒。我对这些结果很满意。
但是在大量数据开始进入之前，这 10 台机器必须首先建立 5k 连接。在此期间，服务器无响应，甚至在我尝试检查运行状况端点时可能超时。我相信这就是导致我的生产车队中断的原因 - 新连接的突然增加。一旦建立连接，服务器就可以轻松处理传入的所有数据。
我已经更新了 nofile ulimit、net.core.netdev_max_backlog、net.ipv4.tcp_max_syn_backlog 和 net.core.somaxconn，但在几秒钟内收到一连串 5k 新连接请求时它仍然挂起。
我可以做些什么来更快地建立新的连接？
编辑：
实际的服务器在 docker 容器中运行。我的网络设置没有应用于容器。接下来要尝试一下，看看它是否有所作为。
编辑编辑：
这一切都在 SSL 中。通过普通 HTTP 快速建立如此多的连接几乎是即时的。所以我必须弄清楚如何更快地建立 TLS 连接。
编辑编辑编辑：
我发现本机 java 安全 ssl 处理程序是瓶颈。切换到netty-tcnative（又名本机 OpenSSL）几乎解决了我的 HTTPS 问题。