优化Jetty以便对数千台机器进行心跳检测？

Question

我有大量的机器（数千及更多），每隔X秒就会向Jetty服务器发出一个HTTP请求，通知它们还活着。对于X的值，我应该使用持久HTTP连接（将受监视机器的数量限制为并发连接数），以及客户端应该重新建立TCP连接的X值（理论上可以监视更多的机器）使用相同的Jetty服务器。）

HTTPS连接的答案如何变化？ （假设CPU不是约束）

这个问题忽略了故意使用多个Jetty Web服务器进行扩展。

更新：基本上问题可以减少到lowResourcesMaxIdleTime的最小建议值。

Answer 1

我想说这不是一个码头扩展问题，而是更多的网络扩展问题，在这种情况下“它取决于”你的网络基础设施。只有你真正知道你的网络是如何布局的，以及为了得到X值而涉及哪种延迟。

从开销的角度来看，持久的HTTP连接当然会产生一些小的影响（好吧我说是次要的，但取决于你的网络），而HTTPS将再次产生更大的影响....但只是从一定量的流量角度来看因为你假设CPU不是约束。

所以从码头的角度来看，它确实不需要涉及这个问题，你似乎最终要求帮助优化线路上的流量字节，所以你真的在寻找最好的协议。由于使用HTTP，您不得不为每个请求弄乱标题，您可能会很好地服务于查看spdy或websocket之类的内容，这将为您提供持久连接，但针对低往返网络开销进行了优化。但是......对于心跳来说，它们似乎有些过分。 :)

Answer 2

如何在不同时间提出要求？假设第一台机器请求，那么你选择一个时间响应那台机器作为下一次机器的心跳（也保持在码头服务器的id /时间），第二台机器请求，你可以选择另一个时间来响应第二台机器。

通过这种方式，您可以让每台机器在不同时间执行心跳请求，从而不会出现并发问题。

如果所有机器可能同时启动，您也可以使用随机时间进行第一次心跳。