asp.net - すべてのアプリケーションに非同期ASP.NETWebページを実装しない理由はありますか？

Question

MSDNの非同期ASP.NETWebページの記事に関して。

実行時間の長いページやサーバーの負荷が高い場合、利点は明らかです。したがって、将来的に需要が高くなる可能性があると思われるプロジェクトで、使用量が増えると、すべてのWebアプリケーションに非同期ASP.NETを標準として実装しない理由はありますか？このアプローチに不利な点はありますか？

二次的な質問：さまざまなWebアプリの状況で、利点が現れ始める実際の研究/例はありますか？それとも、それを吸って見るだけの問題ですか？

Answer 1

あなた自身のリンクから：

I / Oバウンド操作のみが、非同期コントローラークラスの非同期アクションメソッドになるための適切な候補です。I / Oバウンド操作は、完了をローカルCPUに依存しない操作です。I / Oバウンド操作がアクティブな場合、CPUは、外部ストレージ（データベースまたはリモートサービス）からデータが処理される（つまり、ダウンロードされる）のを待つだけです。I / Oバウンド操作は、タスクの完了がCPUのアクティビティに依存するCPUバウンド操作とは対照的です。

非同期ページは無料ではありません、それらは代償を伴います。これらは通常、ページがサービスへの外部呼び出しを行っている場合、または長時間実行され、CPUにバインドされていない操作を実行している場合に適しています。そうしないと、CPUがクラッシュし、非同期になる前の状況が悪化する可能性があります。

アイデアは、CPUを集中的に使用しない作業（長時間実行サービスからの応答を待つ）を実行するアプリケーションのスレッドプールからスレッドを使い果たす場合に非同期を使用することです。そうすることで、アプリケーションはリクエストの処理を続行でき、新しいリクエストのキューイングを開始せず、アプリの応答性が徐々に低下します。

非同期ページを使用する場合と使用しない場合の情報への別のリンクを次に示します。

編集

「長期的」と見なされるものについては、「状況によって異なります」という不器用な答えに直面しています。これを理解するには、アプリケーションのプロファイルを作成し、「長時間実行されている」要求のうち、IISによって処理されるのではなく、後続の要求がキューに入れられる原因となるものがいくつあるかを確認する必要があります。決定は、コンテキスト切り替えのコストのかかる料金を支払うことが、そうすることで得られる利益よりも少ない状況にあることになります。ボトルネックが特定のページまたはサービスであり、着信要求が保留される場合は、非同期作業について考え始めることをお勧めします。ただし、リクエストで多くの作業を行っている可能性もあり、コードをリファクタリングする必要があるのは「コードの臭い」である可能性があります。

結局、それは状況次第です。

これはMSDNからの抜粋です。

一般に、次の条件が当てはまる場合は、非同期パイプラインを使用します。

• 操作は、CPUバウンドではなく、ネットワークバウンドまたはI/Oバウンドです。

• テストでは、ブロック操作がサイトパフォーマンスのボトルネックであり、IISがこれらのブロック呼び出しに非同期アクションメソッドを使用することで、より多くの要求を処理できることが示されています。

• 並列処理は、コードの単純さよりも重要です。

• ユーザーが長時間実行されるリクエストをキャンセルできるメカニズムを提供する必要があります。

リンクはMVCに関するものですが、このアイデアは他の種類のASP.NETにも当てはまります。