我有大量机器(数千台甚至更多)，每 X 秒就会向 Jetty 服务器执行 HTTP 请求以通知它们处于事件状态。对于什么 X 值，我应该使用持久 HTTP 连接(这将受监视的计算机数量限制为并发连接数)，以及对于什么 X 值，客户端应该重新建立 TCP 连接(理论上这将允许监视更多计算机)使用相同的 Jetty 服务器)。
HTTPS 连接的答案会如何变化？ (假设CPU不是限制)
这个问题故意忽略了多个 Jetty Web 服务器的横向扩展。
更新:基本上问题可以减少到lowResourcesMaxIdleTime的最小推荐值。
最佳答案
我想说，这与其说是 jetty 扩展问题，不如说是网络扩展问题，在这种情况下，“这取决于”您的网络基础设施。只有您真正知道您的网络是如何布局的以及涉及什么样的延迟才能得出 X 值。
从开销的角度来看，持久的 HTTP 连接当然会产生一些较小的影响(我说的是较小的影响，但取决于您的网络)，而 HTTPS 将再次产生较大的影响......但只是从流量的角度来看因为您假设 CPU 不是一个限制。
因此，从 jetty 的角度来看，它确实不需要涉及这个问题，您似乎最终是在寻求帮助优化线路上的流量字节，所以您实际上正在寻找此时最好的协议(protocol)。由于使用 HTTP，您必须处理每个请求的 header ，因此您可以查看 spdy 或 websocket 之类的东西，它们将为您提供持久连接，但针对低往返网络开销进行了优化。但是……对于心跳来说，它们似乎有些过分了。 :)
关于jetty - 优化 Jetty 以实现数千台机器的心跳检测？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13986297/