次の方法で共有


ASP.NET パフォーマンスの概要

サーバー上で処理する要求数が大量であってもユーザーの要求にはすばやく応答できる Web アプリケーションを作成することは、インターネットが始まって以来、開発者と IT 担当者の課題となっています。インターネットおよびイントラネットのすべての開発者にとって、Web サイトのパフォーマンスを監視できることは必須であり、ASP.NET はこれを念頭においてデザインされています。

ASP.NET モデルには、以前のバージョンの ASP には含まれていなかった、多数のパフォーマンスの強化機能が組み込まれています。特に、HTTP 要求の処理に関連する 2 つの強化機能があります。まず、ASP.NET ページの初回要求時には Page クラスのインスタンスが動的にコンパイルされます。以前のバージョンの ASP の場合、ページのコードはページ上に出現する順番に、要求されるたびにインタープリタによって処理されていました。共通言語ランタイムの JIT (just-in-time) は、実行時に ASP.NET マネージ ページ コードをコンパイルして、ページを処理するサーバーのネイティブ コードを生成します。次に、初回要求時に Page インスタンスがコンパイルされると、そのインスタンスがサーバー上にキャッシュされます。同じページに対するその後の要求については、キャッシュされたクラスのインスタンスが実行されます。初回の要求以降で、Page クラスが再コンパイルされるのは、ページの元のソースや依存関係が変更された場合だけです。

さらに、ASP.NET はサーバー変数などの内部オブジェクトもキャッシュするので、コードへのアクセスが高速化されます。ASP.NET は .NET Framework の一部なので、共通言語ランタイムが提供するパフォーマンスの強化機能を利用できます。これには前述の JIT コンパイルや、シングルおよびマルチプロセッサ コンピュータ用に微調整された共通言語ランタイムなどが含まれます。

ただし、これらの強化機能を使用しても、作成したコードが、そのアプリケーションが多数の HTTP 要求を同時に処理する場合に適切に動作しなくなる可能性はあります。そのため、アプリケーションをテストして、ユーザーの要件を満たせるかどうかを確認しておく必要があります。アプリケーションが適切に動作することを確認するためのテストの基準として、4 つの一般的なパフォーマンス測定基準があります。

  • 実行時間
    要求の処理にかかる時間。通常は、サーバーからクライアントに先頭のバイトが返されてから、末尾のバイトが返されるまでの時間が計測されます。実行時間はスループットの計算に直接的な影響を及ぼします。
  • 応答時間
    要求が発行されてから、サーバーからクライアントに最初のバイトが返されるまでの時間の長さ。一般に、パフォーマンスの測定基準のうち、クライアント ユーザーが一番認識しやすいのは、この時間の長さです。アプリケーションの応答時間が長い場合は、ユーザーが待ちきれずに別のサイトに移動してしまう可能性があります。アプリケーションの応答時間は、スループット レートとは無関係に変化することがあります (反比例することさえあります)。
  • スケーラビリティ
    より多くのリソース (メモリ、プロセッサ、またはコンピュータ) を割り当てられるにつれて、アプリケーションの動作がどの程度向上していくかを図る尺度。一般にはプロセッサ数に対するスループットの変化率を測定します。
  • スループット
    単位時間内に Web アプリケーションが対応できる要求数。一般には毎秒の要求数が測定されます。スループットは、サーバーにかかる負荷 (クライアント スレッドの数) に応じて変化する可能性があります。通常は、このスループットが最適化を必要とする最も重要なパフォーマンス基準と考えられています。

適切に動作するアプリケーションを作成するには、上記の基準のバランスを保つことが重要です。変化する状況の中でアプリケーションがどのように動作するかを 1 つの測定値だけで特定することはできませんが、いくつかの測定値を組み合わせることで、アプリケーションがどの程度適切に動作しているのかを示すことができます。この種の測定方法、および ASP.NET が提供するパフォーマンス カウンタの詳細については、「ASP.NET アプリケーションのパフォーマンスの監視」を参照してください。

高パフォーマンス アプリケーションの作成方法に関する提案については、「高パフォーマンス ASP.NET アプリケーションの開発」を参照してください。

参照

ASP.NET の最適化