16

私はNettyアプリケーションを書いています。アプリケーションは 64 ビット 8 コア Linux ボックスで実行されています

Netty アプリケーションは、リクエストを受け入れる単純なルーター (受信パイプライン) で、リクエストからいくつかのメタデータを読み取り、データをリモート サービス (送信パイプライン) に転送します。

このリモート サービスは、発信パイプラインに 1 つ以上の応答を返します。Netty アプリケーションは、応答を元のクライアント (着信パイプライン) に送り返します。

何千ものクライアントが存在します。何千ものリモート サービスが存在します。

小規模なテスト (10 クライアント、10 リモート サービス) を行っていますが、99.9 パーセンタイルで期待している 10 ミリ秒未満のパフォーマンスが見られません。クライアント側とサーバー側の両方からレイテンシを測定しています。

SPDY に似た完全な非同期プロトコルを使用しています。FrameDecoder で最初のバイトを処理するときの時間をキャプチャします (私は単に System.nanoTime() を使用します)。channel.write() を呼び出す直前にタイマーを停止します。入力パイプラインから出力パイプラインまで、およびその逆のミリ秒未満の時間 (99.9 パーセンタイル) を測定しています。

また、FrameDecoder の最初のバイトから、(上記の) message.write() で ChannelFutureListener コールバックが呼び出されるまでの時間も測定しました。時間は数十ミリ秒 (99.9 パーセンタイル) でしたが、これが有用なデータであると確信するのに苦労しました。

私の最初の考えは、遅いクライアントがいくつかあるということでした。channel.isWritable() を見て、これが false を返したときにログに記録しました。このメソッドは、通常の状態では false を返しませんでした

いくつかの事実：

  • NIOファクトリーを使用しています。ワーカーのサイズをカスタマイズしていません
  • Nagel を無効にしました (tcpNoDelay=true)
  • キープアライブを有効にしました (keepAlive=true)
  • CPU は 90% 以上の時間アイドル状態です
  • ネットワークがアイドル状態です
  • GC (CMS) が 100 秒ごとに、非常に短い時間呼び出されています。

Netty アプリケーションが思ったほど速く実行されない理由を特定するために従うことができるデバッグ手法はありますか?

channel.write() がメッセージをキューに追加するように感じますが、私たち (Netty を使用するアプリケーション開発者) はこのキューに透過的ではありません。キューが Netty キューなのか、OS キューなのか、ネットワーク カード キューなのか、それとも何なのかわかりません。とにかく、既存のアプリケーションの例を確認していますが、フォローしているアンチパターンは見当たりません

ヘルプ/洞察をありがとう

4

3 に答える 3

2

Netty は、デフォルトで Runtime.getRuntime().availableProcessors() * 2 ワーカーを作成します。あなたの場合は16です。つまり、最大 16 のチャネルを同時に処理できます。他のチャネルは、ChannelUpstreamHandler.handleUpstream/SimpleChannelHandler.messageReceived ハンドラーを解放するまで待機するため、これらの (IO) スレッドで重い操作を行わないでください。そうしないと、他のチャネルがスタックする可能性があります。

于 2013-07-02T06:01:25.120 に答える
0

Netty のバージョンは指定されていませんが、Netty 3 のようです。Netty 4 は現在安定しており、できるだけ早く更新することをお勧めします。超低レイテンシー時間と、数万のクライアントとサービスが必要であると指定しました。これがなかなかうまく混ざりません。NIO は、OIO とは対照的に、本質的に合理的に潜在的です。ただし、ここでの落とし穴は、OIO が期待する数のクライアントに到達できない可能性があることです。それでもなお、OIO イベント ループ / ファクトリを使用して、それがどのように進行するかを確認します。

私自身、TCPサーバーを持っています。これは、localhostでいくつかのTCPパケットを送受信して処理するのに約30ミリ秒かかります（クライアントがソケットを開いてからサーバーが閉じるまで測定）。このような低レイテンシが本当に必要な場合は、接続を開くために必要な SYN/ACK スパムのために TCP から切り替えることをお勧めします。これは 10 ミリ秒の大部分を使用します。

于 2013-08-31T04:36:01.417 に答える