これらの質問のほとんどに対する答えは、サービスの同時実行をどのように管理するかによって異なります。と の設定に依存するため、決定的な答えはありませConcurrencyModeんInstanceContextMode。WCF の同時実行管理により、サービスのスレッド動作とパフォーマンスを微調整できます。同時実行管理に関する長くて骨の折れる (しかし非常に詳細な) 読み物は、MSDN で入手できます。
を使用InstanceContextModeすると、サービスをインスタンス化する方法を定義できます。多くの負荷の高い作業を実行し、多くの呼び出しを処理するサービスの場合、一般的な考え方は、インスタンス化を使用することPerCallです。この設定では、着信クライアント リクエストが毎回サービスの個別のインスタンスで処理されるためです。
ConcurrencyModeメイン プレーヤーである を使用すると、特定の時間にサービス インスタンスにアクセスできるスレッド数を定義できます。ではConcurrencyMode=Single、一度に 1 つのスレッドだけがサービス インスタンスにアクセスできます。これは、 を有効にしているかどうかにも依存します。有効にした場合、サービスが別のリクエストに応答中のSynchronizationConext場合SynchronizationConext=true、クライアントの呼び出しはキューに入れられます。そのため、着信サービス呼び出しは、前の呼び出しが最初に処理されるまでキューに入れられます。とともにConcurrencyMode=Multiple設定すると、任意の数のスレッドがサービス インスタンスへのアクセスを許可されます。つまり、スレッド プールで使用可能なスレッド数 (CPU パワーに直接関係する) が与えられた場合、サービスは可能な限り多くの呼び出しに応答できます。複数同時実行モードの問題点は、SynchronizationContextデフォルトで false に設定されているため、状態が管理されないため、呼び出しを受信して応答する順序でサービスがあまり信頼できないということです。同時実行モードとスレッド セーフに関する簡潔な要約は、MSDN で入手できます。
InstanceContextこれらの設定は、モードと組み合わせて使用すると、サービスのパフォーマンスに影響します。さまざまな同時実行モードとインスタンス コンテキストの設定、およびそれらのパフォーマンスへの影響について説明しているこの非常に優れた記事を参照してください(ただし、結果は自己ホスト環境でのみ得られるようですが、おそらくIIS でホストする場合のタイミングを代表するものではありません)。
サービスの同時実行を管理する方法は、そのパフォーマンスに大きく影響します。理想的には、できるだけ多くのスレッドをサービスで利用できるようにし (ThreadPool の最小スレッド数を増やしてみてください)、サービスが計算リソースを自由に使える限り、着信サービス呼び出しがキューに入れられるのを回避したいと考えています。ただし、マルチスレッドを過度に使用すると、状態管理とクライアント要求に応答する順序が犠牲になります。