これは非常に良い質問です。非同期 IO がなぜ重要なのかを理解するには、この質問を理解することが重要です。新しい async/await 機能が C# 5.0 に追加された理由は、非同期コードの記述を簡素化するためです。サーバーでの非同期処理のサポートは新しいものではありませんが、ASP.NET 2.0 から存在しています。
Steve が示したように、同期処理では、ASP.NET (および WCF) の各要求は、スレッド プールから 1 つのスレッドを取得します。彼がデモを行った問題は、「スレッド プールの枯渇」と呼ばれるよく知られた問題です。サーバーで同期 IO を行うと、IO の間、スレッド プール スレッドはブロックされたままになります (何もしません)。スレッド プール内のスレッド数には制限があるため、負荷がかかると、すべてのスレッド プール スレッドが IO を待ってブロックされ、要求がキューに入れられ始め、応答時間が長くなる可能性があります。すべてのスレッドが IO の完了を待っているため、CPU 占有率が 0% に近いことがわかります (応答時間は非常に長くなりますが)。
あなたが求めていること (なぜ、より大きなスレッドプールを使用できないのですか? ) は非常に良い質問です。実際のところ、スレッド プールの枯渇の問題をこれまでほとんどの人が解決してきた方法は、スレッド プールのスレッド数を増やすことだけでした。Microsoft の一部のドキュメントでは、スレッド プールの枯渇が発生する可能性がある状況の修正として、それが示されています。これは許容できる解決策であり、C# 5.0 までは、コードを完全に非同期になるように書き直すよりもはるかに簡単でした。
ただし、このアプローチにはいくつかの問題があります。
すべての状況で機能する値はありません。必要になるスレッド プール スレッドの数は、IO の期間とサーバーの負荷に直線的に依存します。残念ながら、IO レイテンシはほとんど予測できません。例を次に示します。たとえば、ASP.NET アプリケーションでサード パーティの Web サービスに対して HTTP 要求を行い、完了するまでに約 2 秒かかるとします。スレッド プールの枯渇が発生したため、スレッド プールのサイズをたとえば 200 スレッドに増やすことにすると、正常に動作し始めます。問題は、おそらく来週、Web サービスに技術的な問題が発生し、応答時間が 10 秒に増加することです。スレッドがブロックされる時間が 5 倍長くなるため、スレッド プールの枯渇が突然戻ってきます。
スケーラビリティとパフォーマンス: 2 番目の問題は、それを行う場合でも、要求ごとに 1 つのスレッドを使用することです。スレッドは高価なリソースです。.NET の各マネージ スレッドには、スタック用に 1 MB のメモリ割り当てが必要です。IO が 5 秒間続き、1 秒あたり 500 リクエストの負荷がかかる Web ページの場合、スレッド プールに 2,500 のスレッドが必要になります。つまり、何もしないスレッドのスタック用に 2.5 GB のメモリが必要になります。次に、コンテキスト切り替えの問題が発生し、マシンのパフォーマンスに大きな負担がかかります (Web アプリケーションだけでなく、マシン上のすべてのサービスに影響します)。Windows は、待機中のスレッドを無視するという点でかなりうまく機能しますが、そのような多数のスレッドを処理するようには設計されていません。
したがって、スレッド プールのサイズを大きくすることは解決策の 1 つであり、人々はそれを 10 年間 (Microsoft 自身の製品でさえも) 行ってきました。飢餓を引き起こす IO レイテンシーの急激な増加の慈悲。C# 5.0 までは、非同期コードの複雑さは、多くの人にとって面倒なことではありませんでした。async/await はすべてを変更します。非同期 IO のスケーラビリティの恩恵を受け、同時に単純なコードを記述できます。
詳細: http://msdn.microsoft.com/en-us/library/ff647787.aspx " Web サービス呼び出しの進行中に追加の並列処理を実行する機会がある場合は、非同期呼び出しを使用して Web サービスまたはリモート オブジェクトを呼び出します。可能な場合は、Web サービスへの同期 (ブロッキング) 呼び出しを避けてください。発信 Web サービス呼び出しは ASP.NET スレッド プールのスレッドを使用して行われるためです。ブロッキング呼び出しは、他の着信要求を処理するために使用できるスレッドの数を減らします。