サイド プロジェクトとして、私は現在、昔からプレイしていたゲームのサーバーを作成しています。サーバーを可能な限り疎結合にしようとしていますが、マルチスレッド化に適した設計上の決定は何か疑問に思っています。現在、次の一連のアクションがあります。
- 起動 (作成) ->
- サーバー (クライアントをリッスンし、作成) ->
- クライアント (コマンドをリッスンし、期間データを送信)
ゲームの任意の時点での最大値であるため、平均 100 クライアントを想定しています。全体のスレッド化に関して正しい決定は何でしょうか? 私の現在の設定は次のとおりです。
- 新しい接続をリッスンするサーバー上の 1 つのスレッド。新しい接続でクライアント オブジェクトを作成し、再度リッスンを開始します。
- クライアント オブジェクトには 1 つのスレッドがあり、着信コマンドをリッスンし、定期的なデータを送信します。これは非ブロッキング ソケットを使用して行われるため、利用可能なデータがあるかどうかを確認し、それを処理してから、キューに入れられたメッセージを送信します。ログインは、送受信サイクルが開始される前に行われます。
- アーキテクチャ的に言えば、ゲーム自体の 1 つのスレッド (今のところ) は、クライアント サーバー部分全体とは別のものであると考えています。
これにより、合計 102 スレッドになります。クライアントに送信用と受信用の 2 つのスレッドを与えることも検討しています。これを行うと、レシーバー スレッドでブロッキング I/O を使用できます。つまり、スレッドは平均的な状況ではほとんどアイドル状態になります。
私の主な懸念は、これほど多くのスレッドを使用することでリソースを浪費することです。とにかく対処しなければならないことなので、競合状態やデッドロックについては心配していません。
私のデザインは、1 か 100 かに関係なく、すべてのクライアント通信に単一のスレッドを使用できるように設定されています。通信ロジックをクライアント オブジェクト自体から分離したので、書き直す必要なく実装できました。多くのコード。
主な質問は、アプリケーションで 200 を超えるスレッドを使用するのは間違っているのでしょうか? 利点はありますか？これをマルチコア マシンで実行することを考えていますが、このように複数のコアを最大限に活用できますか?
ありがとう！
これらすべてのスレッドのうち、ほとんどのスレッドは通常ブロックされます。接続が 1 分間に 5 回を超えるとは思わない。クライアントからのコマンドの受信頻度は低く、平均して 1 分間に 20 回程度です。
私がここで得た答えを見ていきます (コンテキストの切り替えは、私が考えていたパフォーマンス ヒットでしたが、あなたがそれを指摘するまで知りませんでした、ありがとう!)受信者、1 つの送信者、およびいくつかの雑多なもの ;-)