web-dev-qa-db-ja.com

リクエスト数が多い場合のJettyの構成

このアプリケーションでは、1秒あたり5,000リクエストを超えるリクエストボリュームを処理する必要があります。これは、私たちのタイプのアプリケーションのJettyで実現可能であると言われています（JSON-HTTP APIをリモートシステムに公開する必要があります。これにより、インバウンド要求と接続が開始されます）。

数千のインバウンドHTTP接続を受信します。それぞれの接続は永続的で、約30秒続きます。次に、リモートサーバーは、これらの各接続で応答できるのと同じ速さで、要求を発生させます。 30秒後に接続が閉じられ、別の接続が開かれます。 100ミリ秒未満で応答する必要があります（ネットワーク通過時間を含む）。

私たちのサーバーは8 GBのRAMを搭載したEC2で実行されており、そのうち4 GBはJava VM（VM $ ===に割り当てられています利用可能なRAM JVMに）。

Webで読んださまざまなヒントに基づいて、現在Jettyを初期化する方法を次に示します。

Server server = new Server();
SelectChannelConnector connector = new SelectChannelConnector();
connector.setPort(config.listenPort);
connector.setThreadPool(new QueuedThreadPool(5120));
connector.setMaxIdleTime(600000);
connector.setRequestBufferSize(10000);
server.setConnectors(new Connector[] { connector });
server.setHandler(this);
server.start();

最初はスレッドプールに512スレッドしかありませんでしたが、5120に増やしてみましたが、これはあまり効果がありませんでした。

この設定では、毎秒300を超えるリクエストを処理するのに苦労しています。それは、いくつかの簡単な計算とGsonシリアル化/逆シリアル化を行っているだけなので、問題はハンドラーではないと考えています。

この負荷を処理しようとしているときに独自のHTTPリクエストを手動で実行すると、応答が始まるまでに数秒かかる場合があります。

Jettyバージョン7.0.0.pre5を使用しています。

解決策、またはボトルネックを分離するための手法についての提案は、いただければ幸いです。

javaperformancehttpjetty
17
sanity

まず、Jetty 7.0.0.pre5は[〜＃〜] very [〜＃〜]古いです。 Jetty 9がリリースされ、多くのパフォーマンス最適化が行われました。

https://www.Eclipse.org/jetty/previousversions.html で7.x行の新しいバージョンをダウンロードします

この次のアドバイスは、

必ずお読みください。

次に、スレッドプールのサイズは受け入れられた要求を処理するためのもので、512が高いです。 5120はばかげています。 50より大きく、500より小さい数を選択してください。

LinuxベースのEC2ノードがある場合は、OSレベルで最大のメリットが得られるようにネットワークを構成してください。 （詳細については、上記のリストの「高負荷」というタイトルのドキュメントを参照してください）

Oracle Java 1.6u38または1.7u10など）の最新のJRE/JDKを使用していることを確認してください。また、64ビットOSを使用している場合は、64ビットJRE/JDKを使用してください。

アクセプター数 SelectChannelConnector.setAcceptors（int） を1から（number_of_cpu_cores-1）までの値に設定します。

最後に、最適化されたガベージコレクションをセットアップし、GCロギングをオンにして、問題が突堤にあるのか、JavaのGCにあるのかを確認します。大量のGC "stop the world"イベントが長時間かかっていることがGCロギングからわかる場合は、パフォーマンスの問題のもう1つの原因がわかります。

26
Joakim Erdfelt