X秒ごとにJettyサーバーへのHTTPリクエストを実行して、それらが生きていることを通知する多数のマシン（数千以上）があります。永続的な HTTP 接続を使用する必要がある X の値 (監視対象のマシンの数を同時接続数に制限する) と、クライアントが TCP 接続を再確立する必要がある X の値 (理論的には、より多くのマシンを監視できるようにする)同じ Jetty サーバーで)。
HTTPS 接続の場合、答えはどのように変わりますか? （CPUが制約ではないと仮定）
この質問では、複数の Jetty Web サーバーによるスケールアウトを意図的に無視しています。
更新: 基本的に、質問は lowResourcesMaxIdleTime の最小推奨値に減らすことができます。
別の時間にリクエストさせてみませんか？最初のマシン リクエストを想定し、次にそのマシンのハート ビートへの次回の時間としてそのマシンに応答する時間を選択し (また、jetty サーバーで ID/時間を保持します)、2 番目のマシン リクエストは、応答する別の時間を選択できます。セカンドマシン。
このようにして、各マシンに異なる時間にハートビート要求を実行させることができるため、同時に問題が発生することはありません。
すべてのマシンが同時に起動する可能性がある場合は、最初のハートビートにランダムな時間を使用することもできます。
これは、桟橋のスケーリングの問題ではなく、ネットワークのスケーリングの問題であると言えます。その場合、ネットワークインフラストラクチャに「依存」します。ネットワークがどのように配置され、X の値を求めるためにどのような遅延が関係しているのかを本当に知っているのはあなただけです。
オーバーヘッドの観点からは、永続的な HTTP 接続はもちろんいくつかの小さな影響を及ぼします (まあ、私はマイナーと言いますが、ネットワークによって異なります)。HTTPS は再び大きな影響を与えます.... CPU は制約ではないと仮定します。
したがって、桟橋の観点からは、実際に質問に関与する必要はありません。最終的には、ネットワーク上のトラフィックのバイトを最適化するための支援を求めているように見えるので、この時点で最適なプロトコルを実際に探しています。HTTP ではリクエストごとにヘッダーをいじる必要があるため、spdy や websocket などの永続的な接続を提供しますが、往復のネットワーク オーバーヘッドが低くなるように最適化されているものを見ると、十分に役立つ場合があります。しかし... ハートビートにはちょっとやり過ぎのようです。:)