私たちのゲーム会社では、クライアントとサーバー間の接続管理に Netty3.2.1 を使用しています。私たちの目標は改善です
- ネットワークの停止などの一時的なシナリオを処理でき、この状況からできるだけ早く回復できる必要があります。
- 既存の接続済みソケットをドロップせずに、単一のサーバーで処理できる接続の数を増やします。
ブリップ シナリオ リアルタイム環境では、ISP の障害が原因でブリップが発生する可能性があるため、既存のすべてのクライアント (既存の接続が切断された後にクライアントが再接続を開始します) の接続が切断され、同時に再接続されます。たとえば、サーバーが 25000 のクライアントに接続されている場合、ブリップ中に 25000 のクライアントすべてがサーバーに同時に接続しようとするため、サーバーに大きな負荷がかかります。Netty の古いバージョンではOP_ACCEPTを有効/無効にする機能が提供されていないため、100 の同時接続 SSL ハンドシェイクの制限を超えて接続のスロットリングを開始しました。制限を超えると、boss スレッドを一時停止します。この機能を提供する Netty 4.0 ベータ版を使用する準備はまだ整っていません。
ストレス テスト中に観察したその他のシナリオは、サーバーに膨大な数の着信接続がある場合で、すべての着信接続を受け入れて安定させるには多くの時間がかかります (25 K の接続で約 30 分、25 K のすべての接続が試行されます)。同時に）。しかし、負荷をゆっくりと上げると、netty は非常に短い時間 (約 3 ～ 5 分) ですべての接続を簡単に受け入れることができます。私たちは、ブリップ シナリオに対応できる回復力を備えたシステムを構築したいと考えています。
- 既存の Netty Jar にいくつかのログを追加しましたが、大量の負荷がかかっているときにクライアントが切断されると、read() メソッドで失敗するようです。
- Netty3.6 Final jar を使用しても、あまり役に立ちませんでした
- 実行ハンドラの使用は役に立ちますか?
- スロットリングを無効にすると、サーバーで OOM 例外が発生しました。
この問題に対処するための可能なアプローチを提案してください。接続を抑制する他の方法はありますか?
詳細と構成の設定
クライアント- JMeter フレームワーク - 2 GB マシン負荷 - 50000 クライアント 1 秒あたりのメッセージ数 - 12000 メッセージ/秒。メッセージは文字列としてのクライアント ハローとサーバー ハローです。すべてのマシンの ulimit は 1,00,000 です
サーバー- 12 コア、HT および 48 GB RAM ワーカー スレッド - 50 (HT のコア数の 2 倍で、コア数は 24 になります) Linux マシンのすべての TCP 内部バッファは、ピーク制限で動作するように構成されています。
Pipeline ハンドラーには、次のハンドラーがあります。
- pipeline.addLast(sslHadler) - 組み込みハンドラーの Netty
- pipeline.addLast(messageEncoder) - バイトをエンコードおよびデコードし、必要に応じてメッセージ フレームに変換します。
- パイプライン.addLast(メッセージデコーダー)
- パイプライン.addLast(ビジネスハンドラー)