1

netty 3.6.5 を使用しており、チャネル パイプラインで OMATPE と組み合わせた ExecutionHandler を使用しています。現在の要件は、イベントを受信順に処理して、できるだけ多くのスレッドにスケーリングすることです。アプリケーションまたはチャネルごとのメモリはまだ制約ではないため、OMATPE でこれらを 0 に設定して無効にしました。

netty コードをいじってみたところ、OMATPE は起動時に固定数のスレッドを使用し、サーバーが受信する接続数には変動があってもその数は変わらないことがわかりました。OMATPE で次の問題が見つかりました。 1. allowCoreThreadTimeOut - この機能は、リクエストの数が少ない場合にコア スレッドの数を減らすためのものです。リクエストを処理するときに、非常に多くのスレッドが作成および破棄されていることに気付きました。ただし、どのスナップショットでも、スレッドの総数は常にコア プール数のままです。これは私たちにとって大きな問題ではありません。setAllowCoreThreadTimeout(false) を呼び出してコア スレッドのタイムアウトを無効にし、少ないスレッド数で開始しようとしています。ただし、次の問題で setMaximumPoolSize が呼び出された場合でも、スレッド数が低スレッド数を超えることはありません。2. Unbounded LinkedBlockingQueue: OMATPE は LinkedBlockingQueue を無制限の容量で使用するため、サーバーへのリクエスト数が増加しても新しいスレッドは追加されません。これにより、キューに入れられたリクエストでレイテンシーが発生しており、処理リソースが不足していない限り、キューに入れないようにしたいと考えています。

順序付けられたチャネル イベントと負荷に基づくスケーラブルなスレッドの要件について、他に代替案や解決策があれば教えてください。また、設定に関するその他の詳細が必要な場合はお知らせください。

4

0 に答える 0