我有大量机器（数千台甚至更多），每 X 秒都会向 Jetty 服务器执行一个 HTTP 请求，以通知它们还活着。对于 X 的什么值，我应该使用持久的 HTTP 连接（将受监控机器的数量限制为并发连接的数量），对于 X 的什么值，客户端应该重新建立 TCP 连接（理论上这将允许监控更多的机器使用相同的 Jetty 服务器）。
HTTPS 连接的答案将如何变化？（假设 CPU 不是约束）
这个问题故意忽略了多个 Jetty Web 服务器的横向扩展。
更新：基本上问题可以减少到lowResourcesMaxIdleTime的最小推荐值。
我想说这与其说是码头扩展问题，不如说是网络扩展问题，在这种情况下，“这取决于”您的网络基础设施。只有你真正知道你的网络是如何布局的，以及为了得出 X 的值所涉及的延迟类型。
从开销的角度来看，持久的 HTTP 连接当然会产生一些较小的影响（我说的是次要的，但取决于您的网络）并且 HTTPS 将再次产生更大的影响......但仅从流量的角度来看，因为您是假设 CPU 不是约束。
所以从码头的角度来看，它真的不需要参与这个问题，你似乎最终会寻求帮助来优化网络上的流量字节，所以你现在真的在寻找最好的协议。由于使用 HTTP，您必须处理每个请求的标头，因此您可能会很好地查看 spdy 或 websocket 之类的东西，它们将为您提供持久连接，但针对低往返网络开销进行了优化。但是......他们似乎有点过分了心跳。:)
让他们在不同的时间提出请求怎么样？假设第一个机器请求，然后您选择一个时间来响应该机器作为下一次对该机器的心跳（同时保持 id/time 在码头服务器），第二个机器请求，您可以选择另一个时间来响应第二台机器。
这样，你可以让每台机器在不同的时间执行心跳请求，这样就不会出现并发问题。
如果所有机器可能同时启动，您还可以对第一次心跳使用随机时间。