ASP.NET APPのパフォーマンスを向上させるための12のヒント–パート2

この投稿は、ASP.NET アプリケーションのパフォーマンスを向上させるための6つのヒントについて説明した前回の投稿の第2部です。この投稿では、アプリケーションのパフォーマンスをさらに向上させる可能性のある6つのヒントについて説明します。前回の記事へのリンクは以下です。

ASP.NET アプリケーションのパフォーマンスを大幅に向上させるための12のヒント–パート1

7. ページを非同期にする

IIS は CLR スレッド プールを使用して、アプリケーションに送信される要求を処理するスレッドを取得します。たとえば、プールに現在 20 個のスレッドがある場合、並列に処理できるのは 20 個の要求のみであり、要求の処理に時間がかかる場合は、数ミリ秒で 100 個の奇妙な要求が殺到すると大惨事になる可能性があります。この場合、一部のリクエストは非常に長い時間がかかり、一部のリクエストでは 404 ステータス コードが返される場合があります。どのようなリクエストでも、リクエストがデータベースに移動してファイルを取得または読み取り/書き込み、Webサービスの呼び出しなど、現在のスコープから外れると、時間の大部分が失われます。その期間中、現在のスレッドは応答が返されるまで待機し続けます。したがって、ページを非同期にし、時間のかかる呼び出しを非同期に処理すると、スループットを大幅に向上させることができます。ページを非同期に処理するには、ページに async ディレクティブを次のように追加します。

また、非同期コードを書くことは、asyncとawaitキーワードの導入により非常に簡単になりました。非同期メソッドを記述し、ページのRegisterAsyncTaskメソッドを使用して使用できます。

8. アプリケーションプールの停止

この機能は、Windows Server 2012 R2 と .NET 4.5.1 で導入されました。IIS には、アプリケーション プールのアイドル タイムアウト設定があり、既定では 20 分に設定されています。これは、20分間リクエストがない場合、ワーカープロセス(w3wp.exe)が停止してサーバーリソースを節約することを意味します。ただし、ワーカープロセスが現在停止しているため、次のリクエストが被害者になるという副作用があります。これは、ワーカープロセスが処理中に再起動して初期化する必要があるためです。ワーカープロセスの再起動は、プロセスの開始、構成の初期化、asp.net の初期化、バイナリのメモリへのロードなどの多くのタスクが含まれているため、高価で時間のかかるプロセスです。

この機能により、プロセスを停止する代わりに一時停止できます。 一時停止後、CPUとメモリのほとんどを解放し、同じサーバーでホストされている他のサイトで使用できるようになります。しかし、リクエストが来るとすぐにアクティブになり、リクエストの処理を開始する状態に維持されます。これは、アクティブ アプリと一時停止されたアプリの概念がある Windows アプリの中断に似ています。 それは2つのフォールドで役立ちます、最初に、アプリケーションを追加することでより最適にサービスを提供でき、タイムアウト後に来るリクエストも、アクティブなものと大きな違いなく迅速に提供されます。どのアプリプールでも次のように構成できます

Select application pool -> advanced settings

9. Global.asax からメソッドを削除する

Global.asaxは、最初のリクエストで1回発生するものもあれば、各リクエストで発生するアプリケーションレベルのメソッドを提供します。ほとんどの場合、このファイルには空のメソッドがあり、内部にコードがない場合でも、asp.net それらのメソッドを実行するように強制されます。各リクエストで、ASP.NET Global.asax で使用可能なメソッドがあるかどうかを確認し、使用可能な場合は、それに応じてロードして実行します。したがって、最初に、空のメソッドを削除する必要があり、ページのライフサイクルの他の場所にコードを配置することでそこから一部のメソッドを削除できる場合でも、それも役立ちます。

10. SqlDataSource を使用しない

GridView などのデータ コントロールのデータ ソースとしてSqlDataSourceを使用しないでください。GridView の場合、ページングが有効になっている場合、ページ番号をクリックすると、データベースからすべてのレコードがフェッチされ、ページングが独自に適用されます。ソートについても同じことが言えます。代わりに、ASP.NET 4.5で導入されたモデルバインディングを使用して、IQueryableクエリを使用し、selectメソッドなどを使用してアイテムのリストを返すことができます。IQueryableは、すべてのレコードではなく10個のレコードなど、データベースから必要なデータのみをフェッチするか、データベースレベルでデータをソートするSQLクエリをスマートに最適化および作成します。これにより、ページングとソートが非常に効率的になります。同様に、QueryableDataSourceまたはObjectDataSourceも使用できます。

11. HTTP Keep-Alive を使用する

これは、応答ヘッダーに存在し、Webアプリケーションのパフォーマンスを大幅に向上させるのに役立つ別の隠された宝石です。この応答ヘッダーは、クライアントとサーバーの接続を特定の期間開いたままにし、複数の要求によって使用されます。接続が開いている場合、新しい接続を作成する時間が節約され、サーバーは非常に迅速に応答を送信できます。デフォルトでは、有効になっており、接続は120秒間開かれます。無効になっている場合、HTTP 1.0 として動作し、接続ごとに 1 つの要求のみが許可されます。IISで次のように構成できます。

IISに移動します ->目的のWebサイトを選択します-> HTTPレスポンスヘッダーを開きます ->右側のアクションタブから[共通のヘッダーを設定]をクリックします

デフォルトでは有効になっています(丸で囲まれた領域を参照)。この機能を検証して、アプリケーションがこの機能を活用しているかどうかを確認します。

注 – IIS 7.5 以降では、このヘッダー タグは応答ヘッダーから削除され、既定では、説明したように有効になっていますが、逆の場合は別のヘッダー タグがあります。無効になっている場合、応答ヘッダーには新しいヘッダーがありますConnection: closeとして利用可能です。これは、リクエスト後に接続が閉じられることを意味します。

12. Remove ETag

1つのHTTPレスポンスヘッダーを見てみましょう

ここでは、ETag (赤で囲まれた部分を参照)として1つの要素があることがわかります。どのように使われているのか、理解してみていきましょう。応答がクライアント キャッシュによって処理されるかどうかは、Cache-Control 属性と Expires 属性とETagの 2 つの項目によって異なります。ETagは、コンテンツごとにWebサーバー上に作成されるハッシュコードであり、ファイルの内容が変更された場合、キャッシュを無効にするハッシュが変更されます。Web ファームのシナリオでは、ハッシュもサーバーに依存するため、コンテンツが同じであっても、異なるサーバーで作成されたハッシュは異なります。そのため、リクエストが別のWebサーバーに送信されると、コンテンツが同じであっても、リクエストはキャッシュから提供されません。したがって、アプリケーションがWebファームでホストされている場合にクライアントキャッシュをより有効に活用するために、このタグ自体を削除する方がよいでしょう。

このヒントは、アプリケーションのパフォーマンスに大きな影響を与える可能性のある、いくつかの非常に重要な構成変更のセットです。

を       IIS が CLR スレッド プールを使用して要求を処理する方法については、前に説明しました。たとえば、アプリケーションが同時に 100 個のリクエストを受信し、この数のスレッドがスレッドプールで使用できない場合、一部のスレッドは待機する必要があります。CLR は、各要求を割り当てるための新しいスレッドの作成を開始します。新しいスレッドの作成はかなり重いプロセスであり、以前のバージョンの .NET では、スレッドの作成速度はスレッドあたり 2 秒でしたが、最新バージョンでは約 0.5 秒です。スレッドあたり0.5秒を考慮すると、80個のスレッドを作成するのに40秒かかるため、応答時間は少なくとも1〜40秒変動することを理解することができます。リクエストの数が500または1000になった場合の状況を想像できます。

​machine.configには、デフォルトで

次のように変更できます。

  maxWorkerThreads = "200" />

​minWorkerThreadの数を 100 に設定したため、各スレッドの作成に費やす時間が短縮され、IIS は要求を迅速に受け取る準備が整います。上記の設定はコアCPUごとに設定されていることに注意してください。

b.      applicationHostには、もう1つの重要な設定があります。最新バージョンのmaxConcurrentRequestsPerCPU (IIS 7+ で利用可能) は 5000 である config(アプリケーション プール レベルで設定可能)は、要件に基づいて調整できます。名前が示すように、アプリケーションが処理できる同時要求の数の制限を設定します。

c.        maxConnectionは、もう1つの非常に重要な構成です。これは、他のシステムに対して作成できる接続の数を制限します。以前のバージョンの of.NET では、デフォルト値は 2 でした。これは、Webサーバーがデータベース/ wcfサービスなどのネットワーク内の別のマシンを呼び出すときに表示されます。つまり、接続性が良好なハイエンドサーバーを使用している場合でも、ある時点では2つの接続しか確立できません。これは、マシンレベルまたはアプリケーションレベルで次のように変更できます。

ここでは、100に変更しました。要件に基づいて、増減することができますが、適度な数に保つことをお勧めします。そうしないと、やり過ぎになる可能性があります。それとは別に、IPアドレスやドメイン情報などのより具体的な詳細を提供して、ネットワーク内の特定のサーバーに限定することができます。

結論

このシリーズでは、次の12のヒントについて説明しましたが、それらのほとんどは、Webアプリケーションのパフォーマンスを大幅に向上させることができるコードを変更せずに簡単に適用できます。これらは：

1. カーネル モード キャッシュ
2. Pipeline mode
3. Remove unused modules
4. runAllManagedModulesForAllRequests
5. Don’t write in wwwroot
6. 未使用のビューエンジンと言語を削除する
7. ページを非同期にする
8. アプリケーションプールの一時停止
9. Global.asax からメソッドを削除する
10. SqlDataSource は使用しないでください
11. HTTP キープアライブを使用する
12. Remove ETag

通常は無視されるヒントについて説明しようとしましたが、それらは大きなパフォーマンス向上の可能性を秘めており、すぐに適用することもできます。バンドルと縮小、IIS圧縮、ViewState、クライアントキャッシングなどのいくつかの一般的なトリックは非常に重要ですが、シリーズには含まれていませんでした。