私は、C# の新しい async キーワードと .NET 4.5 でのサポートについて詳しく読んでおり、それを「正しい方法」で考えるための助けを探しています。
私が最初に考えたのは、待つ必要のないこと (電子メールの送信、ログの記録など) を非同期に行うことで、サイトの応答性を改善できるのではないかということでした。これは、クライアントを待たせずに、ただ起動して忘れたいものです。
しかし、ここでSQL の新しい非同期バージョンについて読んで、混乱してしまいました。DB からの読み取りは、私が待たなければならないものです。データが必要です。それが完了するまで先に進むことはできません。これは使えないということでしょうか？
それとも、SQL 呼び出しをブロックしないことで、リクエスト処理をより IIS に適したものにしているということですか?
これらのことに対する答えは、常に「場合による」です。
IIS からの要求を処理している特定のケースでは、できる限りこれを利用したいのですが、IIS にメリットがある方法でそれを行う必要があります。
たとえば、クライアントが ASP.NET ページにリクエストを送信すると (IIS と .NET について尋ねる質問がこれに当てはまると思いますが、実際にはそれが唯一のオプションです)、サーバーはリクエストを処理するスレッドをスピンアップしました。 . もちろん、多くのリクエストがある場合は、サーバーが処理できる以上のスレッドが必要になる可能性があります。つまり、他のリクエストが処理されている間、一部のリクエストは待機する必要があります。
スレッド (サーバー上の他のスレッドをブロックしている) で他の作業を待機する必要がある場合、(Web サービス、データベースからの) 応答を待っている間、他のスレッドをブロックすることはあまり意味がありません。など）。サーバーにスレッドを返してから、作業を再開する準備が整ったときにサーバーに通知し、応答を提供する方がよいでしょう。
この目的のために、ASP.NET には、応答を待っている間にサーバーが他のことを実行できることをサーバーに知らせるメカニズムがあります。
ASP.NET WebForms には非同期ページ(個人的には少し複雑だと思います) がありますが、ASP.NET MVC にはバージョン 4 の非同期メソッドがあります (タスクベースの非同期パターンにより適しています)。
とはいえ、応答を待っている間に独立して実行する必要がある他の作業がある場合は、スレッドをサーバーに返す理由はなく、自分の作業を行うだけであることに注意してください。これ以上先に進むことはできず、制御を戻します。
ただし、何をするにしても、タスクの結果を待たないでください。サーバーがそのスレッドを他の用途に使用するのをブロックしているため、何もせずに待機しています。これはおそらく、スケーラビリティに対する最大の障害であり、サーバー リソースを保持する必要がない場所を知ることは、高度にスケーラブルなシステムを作成するための鍵の 1 つです。