Netty を使用する場合と、何万もの接続を持つアプリケーションで使用しない場合のパフォーマンスに実際の違いはありますか?
6 に答える
そうではありませんが、Netty を使用する正当な理由は、接続の信頼性を向上させ、問題が発生する可能性があるすべての詳細について心配するのではなく、接続が行うことをコード化することです。(多くの場合、困難な方法を見つけることによってのみ発生します)
Netty は、1,000 接続を超えるスケーリングに役立つ場合があります。ただし、それほど多くの接続が必要ない場合は、単純なコードが最適に機能することがあります。
ピーターが指摘したように、そうではありません。
しかし、Netty はサーバーを構築するための非常に優れた API も提供していることに気付きました。API には多少の学習曲線がありますが、よくできており、新しいサーバーの作成は簡単です。コード的にも非常に効率的であるため、単純なプロトコルと実装があれば、コードはほとんどありません。
これは、HTTP 以外のサーバーを構築している場合のみです。HTTP Web アプリケーションについて話している場合は、試行済みの true を使用してください。単純な HTML ページには Apache、サーブレットが必要な場合は Tomcat。
Netty は非常に高速で、特に接続が多い場合に便利です。
私の経験では:
- 標準の Java IO よりもスケーラブルです。特に、古い同期 Java IO パッケージでは、接続ごとに 1 つのスレッドを結び付ける必要があります。これは、何万もの接続で問題になる可能性があります!
- これは、 Java NIOを使用してカスタム ネットワーキング コードを記述した場合とほぼ同じ速度ですが、このルートをたどるよりも Netty を直接使用する方がはるかに簡単です。
Twitter は検索システムで Netty を使用しました。
実際に Tomcat NIO を使用すると、最大 16,000 の同時接続を取得できます。1 台のマシン上で同時接続していることに注意してください。これは、Jetty との比較としてテストされました。Jetty は、より多くのメモリを与え続けたときに 4000 に達しました。( http://www.javalobby.org/java/forums/t92965.html )
また、REST 機能が組み込まれた Grails (または RestRPC などの単純なプラグイン) のような「構成より規約」のフレームワークを使用すると、API や Webhook などを数秒で簡単に構築できます。
また、必要に応じて、Spring Security プラグインを使用して、誰がどの IP またはどのロールを介してどの API 呼び出しにアクセスできるかをより詳細に制御できます。
Netty には、多数の Grails プラグインが Tomcat NIO の使用をはるかに超えて拡張できるという制限があります。