高性能ネットワーキングのためのNettyの代替手段は何ですか？
私は、ネットワークライブラリを選択して、マイクロ秒を節約できないクライアント/サーバーシステムを実装するプロセスを進めています。メッセージを送受信する独自のプロトコルを実装します。低レベルセレクターの詳細についてあまり心配することなく、サーバーとクライアントを簡単に開発できる優れたNIOフレームワークを探しています。誰もが私にNettyを勧めていますが、フレームワークでチームをコミットする前に、2つまたは3つの他の選択肢を試してみたいと思います。 Nettyについてあまり気に入らなかった点の1つは、独自のByteBuf実装と参照カウントを使用してByteBufferを処理する方法です。誰でもあなたの考えや代替案を共有できますか？
NIOネットワーキングライブラリ を開発しました。これは、GCのガーベッジを生成することなく、ループバックで2マイクロ秒未満で実行します。 Peter Lawreyが述べたように、ネイティブJDKセレクターは大量のガベージを生成しますが、独自のepollセレクターを実装することにより、これらすべてガベージリークを修正しました。セレクタスレッドを待機するビジー状態はレイテンシーには優れていますが、チップを燃やしたり、多くのエネルギーを消費したりしないようにバランスが必要です。セレクターの実装では、低レベルのトリックを使用して、そのバランスを処理する一種の省エネモードを実装します。
CoralReactor の他に、 Grizzly および Mina を確認することもできますが、これらのフレームワークはまだ使用していません。
Netty TCPパフォーマンスベンチマークについては、 こちら をご覧ください。
これは、すべてのマイクロ秒を本当に節約したいという前提です。ほとんどのアプリケーションには、このような厳しい要件はありません。
マイクロ秒を節約したい場合は、専用CPUのスレッドにビジー待機の非ブロッキングNIOを使用します。十分なCPUが必要なため、これはうまくスケーリングしませんが、IOを処理するためのレイテンシを最小化します。分離されたCPUをバインドして、ジッタを最小限に抑えることをお勧めします。
セレクターは、GCの一時停止をブロックしたり、大量のガベージを追加したりするため、セレクターの使用を避ける必要があります。
また、レイテンシを最小限に抑えるために、Solarflareなどの低レイテンシのカーネルバイパスネットワークアダプターを使用することをお勧めします。
プッシュパーサーを使用すると、ダウンロード時に長いメッセージをデコード/解析できます。つまり、開始する前にメッセージ全体が受信されるまで待つ必要はありません。
これらのトリックを組み合わせて使用すると、すべてのリクエストまたはインバウンドイベントから10〜30マイクロ秒節約できます。
Nettyは、スケーラビリティ、つまりネットスループットを向上させるための優れたソリューションですが、ミリ秒の遅延が許容されるサポートWebサービスに基づくほとんどのフレームワークがそうであるように、遅延のコストはわずかです。
少なくともいくつかのScalaを使用しても問題ない場合は、 Spray がNettyの優れた代替手段です。長い目で見れば、Playフレームワークは、たとえばNettyからSprayに移行しようとしています。スプレーは、TCP抽象化のさまざまなレベルを提供します。これらは次のとおりです。
- チャンクレベル
- 要求レベル（HttpRequest/HttpResponse）
- マーシャリングされたオブジェクトレベル
スタックを深く掘り下げるほど、配信される情報は生になります。チャンクレベルAPIでは、元のバイトバッファーにかなり近づきます。私はこの低抽象化レベルを自分で使ったことはありませんが、良いことを聞きました。
Akkaの上にビルドをスプレーIO Java NIOの上に再びビルドされます。すべての機能は、アクターの抽象化をラップして、並列アプリケーションのビルドを容易にします。 AkkaはJava APIを提供しているため、ほとんどの場合このAPIでSprayを使用できるはずです。ただし、おそらく読む必要があるでしょう。 some Scalaソースはときどき。最終的に、SprayはAkkaに完全にマージされます。
編集：スプレーWebサイトからの引用：「スプレーはもはや維持されず、 Akka HTTP に置き換えられました。Playframeworkは、 Play 2.4.X =。 Play 2.6.X バージョンでは、playはAkka HTTPサーバーバックエンドに完全に移行されました。