0

現在、外部クライアントからの接続を通常どおりリッスンし、接続時にリクエストを処理するサーバータイプのアプリケーションを作成しています。

現時点では、私の実装では、クライアントが接続するたびにスレッドのペアが作成されます。1 つのスレッドはソケットから要求を読み取ってキューに追加し、2 つ目のスレッドはキューから要求を読み取って処理します。

基本的に、これらのスレッドをすべて持つのはやり過ぎだと思うかどうか、そして重要なことに、このアプローチが問題を引き起こすかどうかについての意見を探しています.

ほとんどの場合、これらのスレッドはアイドル状態になることに注意することが重要です。私は両方のスレッドで待機ハンドル (ManualResetEvent) を使用しています。リーダー スレッドは、メッセージが利用可能になるまで待機し、利用可能な場合はそれを読み取り、プロセス スレッドのキューにダンプします。Process スレッドは、メッセージがキューにあることをリーダーが通知するまで待機します (ここでも、待機ハンドルを使用します)。特定のクライアントが実際にサーバーを攻撃していない限り、これらのスレッドは待機状態になります。これは費用がかかりますか？

私は少しのテストを終えました.1,000台のクライアントが絶えずしつこく接続されていました-サーバー(つまり、2,000以上のスレッド)で、非常にうまく対処しているように見えました.

4

2 に答える 2

1

あなたの実装には欠陥があると思います。スレッドの作成にはコストがかかり、作成できるスレッドの数には制限があるため、この種の設計は拡張できません。これが、このタイプのほとんどの実装がスレッド プールを使用する理由です。これにより、新しい接続を簡単に管理し、作業が終了したときにスレッドを再利用しながら、スレッドの最大量に簡単に上限を設定できます。

スレッドを使ってアイテムをキューに入れるだけの場合は、 ThreadPool.QueueUserWorkItemメソッドを使用してデフォルトの .NET スレッド プールを使用します。

質問で明確に指定するのに十分な情報を提供していませんが、おそらく、キューをクリアして常に実行している別のスレッドが1つだけ必要な場合があります。待機ハンドルを使用して、何かが追加されたときに通知することができます。

キューへのアクセスを同期するようにしてください。

于 2010-03-03T15:18:49.117 に答える
0

次のパターンを使用することをお勧めします。まず、スレッドプールが必要です - 組み込みまたはカスタム。読み取ることができるものがあるかどうかをチェックするスレッドを用意し、ある場合は Reader スレッドを選択します。次に、読み取りスレッドがキューに入れられ、処理スレッドのプールからのスレッドがそれを選択します。スレッドの数を最小限に抑え、待機状態で費やす時間を最小限に抑えます

于 2010-03-03T15:15:56.287 に答える