ASP.NET の非同期機能を活用する

非同期プログラミングは、主に 2 つの主な理由から、近年多くの注目を集めています。1 つは、UI スレッドをブロックせず、処理が終了する前に UI インターフェイスがハングするのを回避するため、より優れたユーザー エクスペリエンスを提供することです。第 2 に、追加のハードウェアを追加することなく、システムを大幅に拡張するのに役立ちます。

ただし、スレッドを管理するための適切な非同期コードを記述すること自体は退屈な作業です。それにもかかわらず、その大きな利点により、多くの新旧のテクノロジが非同期プログラミングを使用し始めています。 Microsoft は、.NET 4.0 のリリース以来、多大な投資を行ってきました。その後、.NET 4.5 に async キーワードと await キーワードを導入し、非同期プログラミングがこれまでより簡単になりました。

ただし、ASP.NET の非同期機能は最初から利用可能でしたが、それに値する注目を集めることはありませんでした。また、ASP.NET と IIS がリクエストを処理する方法を考慮すると、非同期実装の利点はさらに大きい可能性があります。非同期により、ASP.NET アプリケーションのスケーラビリティを簡単に大幅に向上させることができます。 async キーワードや await キーワードなどの新しいプログラミング構造が導入されると、非同期プログラミングの力の使い方も学ぶ必要があります。

このブログ投稿では、IIS と ASP.NET がリクエストを処理する方法について説明し、次に ASP.NET で非同期を使用できる場所を見て、最後に非同期の利点が最もよく発揮されるいくつかのシナリオについて説明します。

リクエストはどのように処理されますか?

すべての ASP.NET リクエストは、最終的に ASP.NET ハンドラーによって処理される前に IIS を通過します。 まず、IIS が要求を受信し、予備処理を行った後、ASP.NET に送信します (これは ASP.NET 要求である必要があります)。その後、ASP.NET が実際に要求を処理して応答を生成し、その応答が IIS に返送されます。 IIS を介してクライアントにアクセスします。 IIS には、要求のデキュー、IIS モジュールの実行、および要求の ASP.NET キューへの送信を担当するワーカー プロセスがいくつかあります。ただし、ASP.NET 自体はスレッドを作成せず、要求を処理するためのスレッド プールも持たず、代わりに CLR スレッド プールを使用してスレッドを取得し、要求を処理します。したがって、IIS モジュールは ThreadPool.QueueUserWorkItem を呼び出して、CLR ワーカー スレッドによる処理の要求をキューに入れます。 CLR スレッド プールは CLR によって管理され、自動的に調整できる (つまり、必要に応じてプロセスを作成および破棄できる) ことは誰もが知っています。また、スレッドの作成と破棄は重いタスクであることにも注意してください。CLR スレッド プールでは、同じスレッドを複数のタスクに使用できるのはこのためです。リクエストの処理プロセスを説明する図を見てみましょう。

上の画像からわかるように、要求はまず HTTP.sys によって受信され、対応するカーネル レベルのアプリケーション プール キューに追加されます。次に、IIS ワーカー スレッドがキューから要求を取得し、処理して ASP.NET キューに渡します。リクエストが ASP.NET リクエストでない場合は、IIS から自動的に返されることに注意してください。最後に、リクエストを処理するために CLR スレッド プールからスレッドが割り当てられます。

ASP.NET における非同期の使用シナリオは何ですか?

すべてのリクエストは、大きく 2 つのカテゴリに分類できます。

CPU バウンド クラス

I/O バウンド クラス

CPU バウンド クラスのリクエストは CPU 時間を必要とし、I/O バウンド クラスのリクエスト中に同じプロセスで実行されます。本質的にブロックしているため、I/O 操作を実行して応答を返すには他のモジュールに依存する必要があります。リクエストのブロックはアプリケーションのスケーラビリティを向上させる上で大きな障害となっており、ほとんどの Web アプリケーションでは I/O 操作の待機に多くの時間が無駄に費やされています。 したがって、次のシナリオは非同期の使用に適しています:

I/O バインドされたクラス リクエスト (以下を含む)

データベース アクセス

ファイルの読み取り/書き込み

Web サービス呼び出し

ネットワーク リソースへのアクセス

イベント駆動型リクエストSignalR として

複数のデータ ソースからデータを取得するための必須シナリオ

例として、作成された単純な同期ページを非同期ページに変換します。 この例では、(重いデータベースや Web サービスの呼び出しなどをシミュレートするために) 1000 ミリ秒の遅延を設定し、以下に示すように、WebClient を使用してページをダウンロードします。

    protected void Page_Load(object sender, EventArgs e)

    {

        System.Threading.Thread.Sleep(1000);

        WebClient client = new WebClient();

        string downloadedContent = client.DownloadString("https://msdn.microsoft.com/en-us/library/hh873175%28v=vs.110%29.aspx");

        dvcontainer.InnerHtml = downloadedContent;

    }

次に、ページを非同期ページに変換します。ここに含まれる主な手順 手順: 以下に示すように、ページ コマンドに Async = true を追加して、ページを非同期ページに変換します:

    <%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Home.aspx.cs" Inherits="AsyncTest.Home" Async="true" AsyncTimeout="3000" %>

AsyncTimeout (オプション) もここに追加されます。必要に応じて選択してください。

2.将此方法转换成异步方法。在这里把Thread.Sleep 与 client.DownloadString 转换成异步方法如下所示：

    private async Task AsyncWork()

    {

        await Task.Delay(1000);

        WebClient client = new WebClient();

        string downloadedContent = await client.DownloadStringTaskAsync("https://msdn.microsoft.com/en-us/library/hh873175%28v=vs.110%29.aspx ");

        dvcontainer.InnerHtml = downloadedContent;
 
    }

3.现在可以直接在 Page_Load （页面加载）上调用此方法，使其异步，如下所示:

    
    protected async void Page_Load(object sender, EventArgs e)

    {
        await AsyncWork();
    }

但是这里的 Page_Load 返回的类型是async void，这种情况无论如何都应该避免。我们知道，Page_Load 是整个页面生命周期的一部分，如果我们把它设置成异步，可能会出现一些异常情况和事件，比如生命周期已经执行完毕而页面加载仍在运行。 因此，强烈建议大家使用 RegisterAsyncTask 方法注册异步任务，这些异步任务会在生命周期的恰当时间执行，可以避免出现任何问题。

    protected void Page_Load(object sender, EventArgs e)
    {
        RegisterAsyncTask(new PageAsyncTask(AsyncWork));
    }

现在，页面已经转换成了异步页，它就不再是一个阻塞性请求。

笔者在 IIS8.5 上部署了同步页面和异步页面，并使用突发负载对两者进行了测试。测试结果发现，相同的机器配置，同步页面在2-3秒内只能提取1000个请求，而异步页面能够为2200多个请求提供服务。此后，开始收到超时（Timeout）或服务器不可用（Server Not Available）的错误。虽然两者的平均请求处理时间没有多大差别，但是通过异步页面，可以处理两倍以上的请求。这足以证明异步编程功能强大，所以应该充分利用它的优势。

ASP.NET中还有几个地方也可以引入异步：

编写异步模块

使用IHttpAsyncHandler 或 HttpTaskAsyncHandler 编写异步HTTP处理程序

使用web sockets 或 SignalR

结论

本篇博文中,我们讨论了异步编程，而且发现，新推出的async 和 await关键字，使异步编程变得十分简单。我们讨论的话题包括 IIS和ASP.NET如何处理请求，以及在哪些场景中异步的作用最明显。另外，我们还创建了一个简单示例，讨论了异步页面的优势。最后我们还补充了几个ASP.NET中可以使用异步的地方。