以下は、高性能ソケットコンポーネントを実装する際の問題点の概要です。もし数千の同時処理アプリケーションだけを扱うなら、コード作成に注意を払うこともできますが、数万から数万の同時接続アプリケーションに直面しなければなりません。 以下の質問の要約は、本申請書の作成に大いに役立つと考えられています。
SocketAsyncEventArgs
このオブジェクトは.NET 2.0 sp1以降に提供され、主に高性能なソケットデータの送受信処理の実装に使われます(より詳細な紹介はMSDNをご覧ください)。このオブジェクトは、送信・受信関連の送信バッファを設定する3つの方法を提供します。SetBuffer(Byte(), Int32、Int32、BufferList。後者と共存することはできません( MSDNがその理由を説明しています。SetBuffer(Byte(), Int32, Int32)やBufferListを設定する際は、プログラムのライフ期間中、SocketAsyncEventArgsインスタンスごとに1回だけ設定するようにしてください。この設定は非常にリソースを消費することがあります。 SocketAsyncEventArgsを構築する際には、SetBuffer(Byte(), Int32, Int32)を通じてデータバッファを設定し、その後SetBuffer(Int32, Int32)で処理することが推奨されます。 BufferListを設定したい場合は、<byte>IListが参照するバイト[]ソースを変更しない方が良い<ArraySegment>です。 変更すると、SocketAsyncEventArgsがバッファを再割り当てし、効率に影響します。
SocketAsyncEventArgs プール
前述の通り、この目的を達成するためには、SocketAsyncEventArgsが参照するバッファをできるだけ変更しないようにしてください。 したがって、SocketAsyncEventArgsアプリケーションプールを構築し、プログラム開始時にできるだけSocketAsyncEventArgsオブジェクトを初期化する必要があります。 SocketAsyncEventArgsの作成を減らすだけでなく、プールを構築することでメモリを大幅に節約できます。 主な理由は、各メッセージの大きさを知ることができないからです。もちろん、設計前にメッセージに最大限界を設定し、SocketAsyncEventArgsに対応するバッファを設定することができます。 しかし、すべてのメッセージに最大長さがあるわけではないため、これはメモリの大きな無駄です。 SocketAsyncEventArgsに適切なバッファサイズを割り当て、プールを通じた呼び出しを提供し、1つ以上のSocketAsyncEventArgsにメッセージを柔軟に書き込むか、複数のメッセージを1つのSocketAsyncEventArgsに保存して処理します。
キュー
多くの慣行では、データを受信した後にスレッドを直接開いたり、スレッドプールに送ったりするものがあり、これはスレッドの作業、特に待ち時間の管理をうまく管理できないため非常に良くありません。 カスタムスレッド+キューでは、どの作業を担当するスレッド数を制御でき、キューに入った作業はキュー内にのみ存在します。 スレッドの数や待機するラインの数が多くないため、スレッドスケジューリングによってOSがリソースを失うことになります。
データの統合遅延
遅延マージデータ伝送は、過剰なネットワークIO操作の問題を解決する手段であり、多くのシナリオでは使われませんが、ゲームサーバーでは一般的です。 以前誰かに質問がありました。もしシーンに400人のユーザーがいる場合、各ユーザーの環境変更が他のユーザーに伝えるということです。 結合されたデータが使われなければ、非常に恐ろしいネットワークIO操作が発生し、IO操作番号システムが処理しにくいことになります。 したがって、現在のアプリケーションに適した遅延間隔内でデータをマージし送信する必要があります。 |
掲載地 2016/11/02 9:53:37
|
|
|
