Netty 3 から Netty 4 にアップグレードすると、パフォーマンスが約 45% 低下します。
パフォーマンス テストを行いながら、Netty 3 と Netty 4 のスレッド ダンプを比較しました。Netty 4 サーバーが書き込み操作により多くの時間を費やしたようです。ただ、Netty 3ベースのサーバーでNetty 4ベースのクライアントを使った場合、パフォーマンスの低下は5%程度しかないので、サーバー側に原因があるのではと推測しましたが、原因がわかりません。
誰かアドバイスをくれませんか？
コードは次の URL で確認できます: https://code.google.com/p/nfs-rpc/source/browse/#svn%2Ftrunk%2Fnfs-rpc-netty4
Netty4 は新しいスレッド モデルを導入しました。パフォーマンスを向上させるためにコードを調整する必要があるかもしれません。以下はNetty Wikiからのいくつかのポイントであり、netty4 にはさらに多くの変更点があります。
3.5 では矛盾を修正する試みがありましたが、3.x には明確に定義されたスレッド モデルはありません。4.0 では、ユーザーがスレッドの安全性をあまり気にせずに ChannelHandler を作成できるようにする厳密なスレッド モデルが定義されています。
ChannelHandler に @Sharable アノテーションが付けられていない限り、Netty は ChannelHandler のメソッドを同時に呼び出すことはありません。これは、ハンドラー メソッドのタイプ (インバウンド、アウトバウンド、またはライフサイクル イベント ハンドラー メソッド) に関係ありません。
ユーザーは、インバウンドまたはアウトバウンドのイベント ハンドラー メソッドを同期する必要がなくなりました。
4.0 では、@Sharable で注釈が付けられていない限り、ChannelHandler を複数回追加することはできません。
Netty によって行われる各 ChannelHandler メソッド呼び出しの間には、常に事前発生関係があります。
ユーザーは、ハンドラの状態を保持するために volatile フィールドを定義する必要はありません。ユーザーは、ハンドラーを ChannelPipeline に追加するときに EventExecutor を指定できます。
指定されている場合、ChannelHandler のハンドラー メソッドは、指定された EventExecutor によって常に呼び出されます。
指定されていない場合、ハンドラー メソッドは常に、関連付けられた Channel が登録されている EventLoop によって呼び出されます。
ハンドラーまたはチャネルに割り当てられた EventExecutor および EventLoop は、常にシングルスレッドです。
ハンドラー メソッドは、常に同じスレッドによって呼び出されます。
マルチスレッドの EventExecutor または EventLoop が指定されている場合、スレッドの 1 つが最初に選択され、選択されたスレッドが登録解除されるまで使用されます。
同じパイプライン内の 2 つのハンドラーが異なる EventExecutor に割り当てられている場合、それらは同時に呼び出されます。共有データが同じパイプライン内のハンドラーによってのみアクセスされる場合でも、複数のハンドラーが共有データにアクセスする場合、ユーザーはスレッド セーフに注意を払う必要があります。ChannelFuture に追加された ChannelFutureListeners は、future の関連付けられた Channel に割り当てられた EventLoop スレッドによって常に呼び出されます。