1

サーバーアプリケーションがフレームごとにビデオを受信するC#システムがあり、その責任はこのフレームを接続されているすべてのクライアントに送信することです。フレームをダウンロードして保存するスレッドがあります。そして、他のクライアント接続スレッドは、これらの格納されたフレームを読み取り、クライアントに送信します。今、私の疑問は、マルチスレッド環境のフレームを保存する最良の方法はどれかということです。

私は2つのアプローチを計画しました。1 つは Queue クラスを使用し、ロックでラップして enque-deque を使用することです。もう 1 つのアプローチは、フレームをファイルにダンプすることです。このファイルは、すべての読み取りおよび書き込みスレッドによって共有モードで開かれます。どちらがよりパフォーマンス指向になりますか? これを行うための他のより良い方法はありますか?

上記の 2 つのアプローチに対する私の仮定の一部を以下に示します。1) キューをロックするとパフォーマンスが低下する可能性があります。2) ファイルは共有モードで開かれ、個別のファイル ポインタを持つため、ファイル IO をロックする必要はありません。3) キュー アプローチの場合、RAM のメモリ制限を管理するためにキューの長さを定義する必要があります。これらのメモリ制限の制約には、キューのオーバーフローなどの他の状況を管理するためのテクティクスがさらに必要です。3) キューから複数のクライアントに同じフレームを送信するには、deque の変更を探す必要があります。4) ファイル IO は、キュー管理よりも遅くなります。

PS メモリ マップト ファイル IO は、私のシナリオでより多くのパフォーマンスを達成するのに役立ちますか?

あらゆる種類の長所/短所/コメントを提供してください。ありがとう。

4

1 に答える 1

1

両方が機能するはずです-ファイルシステムからのロックおよび/または読み取り/書き込みのオーバーヘッドが、データのストリーミングイン/アウトの速度に匹敵するかどうかは本当に疑わしいです。

理論的な観点から、選択は、ストリーミングできる速度と比較して、データをストリーミングできる速度に大きく依存すると述べました。両方がほぼ同じである場合は、インメモリ構造を使用できます。キューは急速にいっぱいになり続けます (キューとデキューがほぼ同じ速度で発生するため)。

最後に、両方の長所を活かすハイブリッド アプローチをいつでも選択できます。メモリ内キューを使用できますが、キュー要素は実際のビデオ フレームである必要はありません。データがどこにあるか (メモリ内またはファイル内) を示すデータ構造である可能性があります。そうすれば、キューイング/デキューイング ロジックはデータ ストアから独立します。実際のストレージ コードは、メモリの可用性に基づいて格納する場所を決定できます。たとえば、最大 50 フレームをメモリに格納し、それ以降のフレームはファイルに移動します (1 つまたは複数)。メモリ内フレームが送信されると、そのスロットは空になり、ダウンロードされる次のフレームはそこに移動できます。

于 2013-01-08T07:31:21.123 に答える