パフォーマンスの概要

[アーティクル]
10/22/2014

更新 : 2007 年 11 月

パフォーマンスは、Web サイトまたはプロジェクトを成功させるうえで重要な要素となる可能性があります。このトピックでは、サイトのパフォーマンス向上のガイドラインについて説明し、ベストプラクティスに関するドキュメントへのリンクを紹介します。

このトピックの内容は次のとおりです。

ベストプラクティス
背景
コード例

ベストプラクティス

ASP.NET Web サイトのパフォーマンスに関する全体的なベストプラクティスが説明されている、Microsoft Web サイトのリソースへのリンクを次に示します。

ページのトップへ

背景

このセクションでは、ASP.NET Web アプリケーションのパフォーマンスを最大化するためのテクニックを示します。ガイドラインは次のセクションに分けられます。

ページコントロールおよびサーバーコントロールの処理
状態管理
データアクセス
Web アプリケーション
コーディングの技法

ページコントロールおよびサーバーコントロールの処理

次のガイドラインでは、ASP.NET のページおよびコントロールを効率的に使用するための推奨方法を示します。

サーバーへの不要なラウンドトリップを回避する。 場合によっては、完全なポストバックを実行せずに、ASP.NET AJAX および部分ページレンダリングを使用してブラウザコードでタスクを実行できます。たとえば、ASP.NET AJAX 機能を使用して、ユーザー入力がサーバーに送信される前に入力をブラウザで検証できます。詳細については、「ASP.NET AJAX の概要」および「部分ページレンダリングの概要」を参照してください。
一般に、情報をサーバーに送信して検証やデータストアへの書き込みを行う必要がない場合は、サーバーへのラウンドトリップを避けることで、ページのパフォーマンスを向上させることができます。これにより、ユーザーの操作性も向上します。
カスタムサーバーコントロールを開発する場合は、いくつかの機能について、クライアントスクリプトを出力する設計にすることを検討してください。これにより、情報を Web サーバーに送信する回数が大幅に低減されます。詳細については、「ASP.NET カスタムサーバーコントロールの開発」および「Microsoft AJAX Library を使用したカスタムクライアントスクリプトの作成」を参照してください。
Page オブジェクトの IsPostBack プロパティを使用して不要な処理を回避する。 ページが最初に要求されたときにしか実行する必要のないコードは、ポストバックのたびに実行されることがないようにします。IsPostBack プロパティをテストすると、サーバーコントロールイベントへの応答としてページが実行されているかどうかに応じて、条件付きでコードを実行できます。
特別な理由がない限りバッファリングはオンにしておく。 ASP.NET Web ページのバッファリングを無効にすると、パフォーマンスが大幅に低下します。詳細については、Buffer プロパティを参照してください。
同一アプリケーション内の ASP.NET ページ間でリダイレクトするには、Server オブジェクトの Transfer メソッドを使用するか、ページ間ポスティングを使用する。 詳細については、「ユーザーをほかのページへリダイレクトする」を参照してください。

状態管理

次のガイドラインでは、状態管理の効率化を図るための推奨方法を示します。

サーバーコントロールのビューステートは必要な場合にだけ保存する。 ビューステートを使用すると、サーバーコントロールはラウンドトリップ時にプロパティ値を再設定できるため、コードを記述する必要がなくなります。ただし、ビューステートはサーバーとの間で非表示のフォームフィールドとして送受信されるため、パフォーマンスとページサイズに影響を及ぼします。ラウンドトリップごとにサーバーコントロールをデータにバインドする場合は、データバインディングの処理中にコントロールの値が新しい値で置き換えられるため、保存されたビューステートは使用されません。この場合は、ビューステートを無効にすることで処理時間を短縮し、ページサイズを削減できます。

既定では、すべてのサーバーコントロールでビューステートが有効になります。特定のコントロールのビューステートを無効にするには、次の例に示すように、コントロールの EnableViewState プロパティを false に設定します。

<asp:datagrid EnableViewState="false" datasource="..." 
   runat="server"/>

次の例に示すように、@ Page ディレクティブを使用して、ページのビューステートを無効にすることもできます。

<%@ Page EnableViewState="false" %>

これは、ページでポストバック処理が必要ではない場合に便利です。

メモ :
ユーザーコントロールについてビューステートを有効にするかどうかを指定する EnableViewState 属性は、@ Control ディレクティブでもサポートされます。

ページのビューステートのサイズを分析するには、@ Page ディレクティブで trace="true" を設定し、ページのトレースを有効にします。トレース出力で、[コントロールのツリー] の表の [Viewstate] 列を確認します。詳細については、「ASP.NET トレースの概要」を参照してください。

必要でない限りビューステートは暗号化しない。 ビューステートの暗号化を行うと、非表示のビューステートフォームフィールド内のビューステート値が読み取られるのを防ぐことができます。たとえば、レコードへの更新を調整するために、DataKeyNames プロパティに識別子フィールドを保持する GridView コントロールがページに含まれている場合、ビューステートを暗号化します。この識別子情報を読み取られないようにするために、ビューステートを暗号化できます。ただし、暗号化を行うと、その初期化時にパフォーマンスが一定量低下し、また暗号化の対象となるビューステートのサイズによっては、さらにパフォーマンスが低下します。暗号化は、ページが読み込まれるたびに実行されます。したがって、ページが最初に要求されたときだけでなく、ポストバックのたびに、パフォーマンスに対する同じ影響が発生します。

セッション状態を使用していない場合は無効にする。 ページのセッション状態を無効にするには、次の例に示すように、@ Page ディレクティブの EnableSessionState 属性を false に設定します。

<%@ Page EnableSessionState="false" %>

メモ :
セッション変数にアクセスする必要のあるページがあっても、そのページがセッション変数の作成または修正を行わない場合は、@ Page ディレクティブの EnableSessionState 属性を ReadOnly に設定しておきます。

セッション状態は、ASP.NET Web サービスメソッドに対しても無効化できます。詳細については、「ASP.NET アプリケーションサービスの概要」を参照してください。

セッション状態をアプリケーションに対して無効にするには、次の例に示すように、アプリケーションの Web.config ファイルの SessionState セクションで、Mode 属性を Off に設定します。

<sessionState mode="Off" />

アプリケーションに適したセッション状態プロバイダを選択する。 ASP.NET には、アプリケーション用にセッションデータを格納する複数の方法が用意されています。これには、インプロセスセッション状態、Windows サービスとしてのアウトプロセスセッション状態、および SQL Server データベースのアウトプロセスセッション状態があります (カスタムセッション状態プロバイダを作成し、指定したデータストアにセッションデータを格納することもできます)。それぞれにメリットがありますが、速さという点では、インプロセスセッション状態が最も優れています。セッション状態の少量のデータにのみセッション状態を使用する場合は、インプロセスプロバイダを使用します。複数のプロセッサまたは複数のコンピュータにわたってアプリケーションがスケールアップされる場合や、サーバーやプロセスが再起動されてもセッションデータを保持する場合は、アウトプロセスセッション状態を使用します。詳細については、「ASP.NET セッション状態の概要」を参照してください。

データアクセス

次のガイドラインでは、アプリケーションのデータアクセスの効率化を図るための推奨方法を示します。

データアクセスに SQL Server およびストアドプロシージャを使用する。 SQL Server は、高性能でスケーラブルな Web アプリケーションを作成するデータストレージとして推奨される選択です。マネージ SQL Server プロバイダを使用する場合は、可能であれば SQL コマンドの代わりにコンパイル済みストアドプロシージャを使用します。これにより、さらにパフォーマンスを向上させることができます。詳細については、「パラメータの構成 (ADO.NET)」を参照してください。
SqlDataReader クラスを使用する。 SqlDataReader クラスは、SQL Server データベースから取得される前方向の読み取り専用データストリームを作成します。SqlDataReader クラスは、SQL Server のネイティブなネットワークデータ転送形式を使用して、データ接続から直接データを読み込みます。SqlDataReader クラスは DataSet クラスよりもパフォーマンスに優れているため、実用的であればこのクラスを使用してください。たとえば、データコントロールを SqlDataSource コントロールにバインドするときは、DataSourceMode プロパティを DataReader に設定することで、パフォーマンスを向上させることができます (ただし、データリーダーがサポートする機能は、DataSet モードよりも少なくなります)。SqlDataReader クラスは IEnumerable インターフェイスも実装しているため、サーバーコントロールをバインドすることもできます。詳細については、SqlDataReader クラスと「ASP.NET でのデータアクセス」を参照してください。
可能な場合はデータとページ出力をキャッシュする。 ページやデータをページ要求ごとに動的に計算する必要がない場合は、ASP.NET キャッシュを使用します。可能であれば、特にトラフィックの集中が予測される状況に対して、ページとデータ要求をキャッシュするように設計します。キャッシュを適切に使用すると、.NET Framework の他の機能を使用する場合よりもサイトのパフォーマンスを向上させることができます。

ASP.NET キャッシュを使用するときは、次のガイドラインに従います。まず、あまり多くの項目をキャッシュしないようにします。キャッシュされた項目には、それぞれサーバーメモリが必要になるためです。たとえば、簡単に再計算できる項目やあまり使用されない項目はキャッシュしないでください。次に、キャッシュされた項目に短い有効期限を割り当てないようにします。すぐに有効期限が切れる項目があると、クリーンアップコードやガベージコレクタのために余分な作業が発生する可能性があります。項目の期限切れによるキャッシュの更新は、ASP.NET アプリケーションのパフォーマンスオブジェクトに関連付けられた Cache Total Turnover Rate パフォーマンスカウンタを使用して監視できます。特に有効期限前に項目が削除される場合は、高い回転率が問題となっている可能性があります (このような状態をメモリ圧迫と呼ぶこともあります)。

ページ出力とデータの要求をキャッシュする方法については、「ASP.NET のキャッシュの概要」を参照してください。
SQL キャッシュの依存関係を適切に使用する。 ASP.NET では、SQL Server からデータをキャッシュするために、使用している SQL Server のバージョンに応じて、テーブルベースポーリングとクエリ通知の両方がサポートされます。テーブルベースポーリンクは、すべてのバージョンの SQL Server でサポートされています。テーブルベースポーリングでは、テーブルのいずれかのデータが変更されると、テーブルに依存するすべてのキャッシュ項目が無効になります。これにより、キャッシュ内で不要な処理が発生することがあります。頻繁に変更されるテーブルに対してテーブルベースポーリングを行うことはお勧めしません。テーブルベースポーリングは、たとえば、カタログテーブルのようにあまり変更されないテーブルに向いています。オーダーテーブルのような頻繁に更新されるテーブルにはお勧めしません。

クエリ通知は、SQL Server 2005 以降のバージョンでサポートされています。クエリ通知では、SQL クエリを使用して目的の行のセットの変更を検出します。これにより、テーブルが変更されたときに送信される通知の数が低減されます。クエリ通知のパフォーマンスは、テーブルベースポーリングよりも優れています。ただし、何千ものクエリには対応できません。

SQL キャッシュの依存関係の詳細については、「チュートリアル : SQL Server での ASP.NET の出力キャッシュの使用」および「SqlCacheDependency クラスによる ASP.NET のキャッシュ」を参照してください。
UI (ユーザーインターフェイス) ページングと並べ替えではなく、データソースページングと並べ替えを使用する。 DetailsView や GridView などのデータコントロールの UI ページング機能は、ICollection インターフェイスをサポートするすべてのデータソースオブジェクトで使用できます。各ページング操作において、データコントロールはデータソースに対してデータコレクション全体を問い合わせ、表示する行を選択し、残りのデータは無視します。

データソースコントロールに DataSourceView が実装されていて、かつ CanPage プロパティから true が返される場合、データコントロールは UI ページングの代わりにデータソースページングを使用します。この場合、データコントロールは、表示される各ページに必要な行のみを要求します。したがって、データソースページングは UI ページングよりも効率的です。標準 ASP.NET コントロールの中でデータソースページングをサポートしているのは、ObjectDataSource データソースコントロールと LinqDataSource データソースコントロールだけです。他のデータソースコントロールでデータソースページングを有効にするには、使用するデータソースコントロールから継承して、その動作を変更します。
**LinqDataSource コントロールでの同時実行制御には Timestamp 列を使用する。 ** SQL Server データベーステーブルに Timestamp 列 (SQL Server データ型) が含まれていない場合、LinqDataSource コントロールは、元のデータ値を Web ページに格納することでデータの同時実行をチェックします。LINQ to SQL は、データを更新または削除する前に、元の値をデータベースと比較します。この方法では、データレコードに多くの列が含まれている場合や、列の値が大きい場合に、Web ページのサイズが大きくなる可能性があります。また、ページで公開するつもりのないデータがレコードに含まれていると、セキュリティ上のリスクが発生することにもなります。データベーステーブルに Timestamp 列が含まれている場合、LinqDataSource コントロールは、今後の比較用のタイムスタンプ値のみを格納します。LINQ to SQL は、元のタイムスタンプがテーブル内の現在のタイムスタンプと一致するかどうかを確認することで、データの同時実行をチェックできるようになります。タイムスタンプの詳細については、MSDN Web サイトの「timestamp (Transact-SQL)」を参照してください。

**イベント検証によるセキュリティ上の利点とそのパフォーマンス低下とのバランスを取る。 **System.Web.UI.WebControls クラスおよび System.Web.UI.HtmlControls クラスから派生したコントロールは、イベントが、そのコントロールによってレンダリングされたユーザーインターフェイスから発生したものかどうかを検証できます。これにより、コントロールがなりすましによるイベント通知に応答することを防ぐことができます。たとえば、イベント検証を使用することにより、DetailsView コントロールでは、悪意のあるユーザーが、本来はコントロールでサポートされていない Delete の呼び出しを実行し、コントロールを操作してデータを削除するのを防ぐことができます。イベント検証には、多少のパフォーマンスの低下が伴います。EnableEventValidation 構成要素と RegisterForEventValidation メソッドを使用して、イベントの検証を制御できます。検証によるパフォーマンスの低下の程度は、そのページ上にあるコントロールの数によりますが、数パーセントの範囲内です。

セキュリティに関するメモ :
イベント検証は無効にしないことを強くお勧めします。イベント検証を無効にする前に、アプリケーションに意図しない影響を与える可能性のあるポストバックが発生しないことを確認してください。

**SqlDataSource コントロールのキャッシュ、並べ替え、およびフィルタ処理を使用する。 **SqlDataSource コントロールの DataSourceMode プロパティを DataSet に設定すると、SqlDataSource コントロールでクエリからの結果セットをキャッシュできます。キャッシュされたデータは、SqlDataSource コントロールのフィルタ処理および並べ替えの操作で使用できます。データセット全体をキャッシュし、FilterExpression プロパティと SortParameterName プロパティを使用して並べ替えとフィルタ処理を行うと、アプリケーションの処理速度が速くなります。ユーザーが UI でデータの並べ替えやフィルタ処理を行っても、そのたびにデータソースコントロールで Where 句と Sort By 句を持つ SQL クエリを作成してデータベースにアクセスする必要はなくなります。

Web アプリケーション

次のガイドラインでは、Web アプリケーションの全体的な効率化を図るための推奨方法を示します。

サイトをプリコンパイルする。 Web アプリケーションでは、ASP.NET Web ページなどのリソースが最初に要求されたときにバッチコンパイルが実行されます。アプリケーション内のページがコンパイルされていない場合、バッチコンパイルはディレクトリ内のすべてのページをチャンク単位でコンパイルし、ディスクおよびメモリの使用率を向上させます。ASP.NET コンパイルツール (Aspnet_compiler.exe) を使用して、Web アプリケーションをプリコンパイルできます。埋め込み先コンパイルの場合、コンパイルツールは ASP.NET ランタイムを呼び出して、ユーザーが Web サイトのページを要求するときと同じように Web サイトをコンパイルします。Web アプリケーションは、UI マークアップが保持されるようにプリコンパイルすることも、ソースコードを変更できないようにプリコンパイルすることもできます。詳細については、「方法 : ASP.NET Web サイトをプリコンパイルする」を参照してください。
デバッグモードを無効にする。 製品版アプリケーションを配置する前またはパフォーマンス測定を実行する前には、必ずデバッグモードを無効にします。デバッグモードが有効になっていると、アプリケーションのパフォーマンスが低下することがあります。デバッグモードの設定の詳細については、「ASP.NET 構成ファイルの編集」を参照してください。
Web サーバーコンピュータおよび特定のアプリケーションに合わせて各構成ファイルを調整する。 ASP.NET の既定の構成では、最も一般的なシナリオに対応できるように最大限の機能セットが有効になります。アプリケーションのパフォーマンスを向上させるために、使用する機能に応じて既定の構成設定の一部を変更できます。考慮する必要のある構成の変更を次の一覧に示します。
- **認証は、認証を必要とするアプリケーションに対してのみ有効にする。**既定では、ASP.NET アプリケーションの認証モードは Windows で、統合 NTLM ではありません。多くの場合、Machine.config ファイルでは認証を無効にし、認証を必要とするアプリケーションの Web.config ファイルでのみ認証を有効にすることをお勧めします。
- 要求および応答のエンコード設定に合わせてアプリケーションを構成する。 ASP.NET の既定のエンコードは UTF-8 です。アプリケーションで ASCII 文字しか使用しない場合は、アプリケーションを ASCII に合わせて構成するとパフォーマンスが若干向上します。
- アプリケーションの AutoEventWireup を無効にする。 Web.config ファイルで AutoEventWireup 属性を false に設定すると、ページでは、名前の一致に基づいたページイベントのメソッドへのバインド (Page_Load など) が行われなくなります。これにより、パフォーマンスが若干向上します。ページイベントを処理するには、2 つの方法があります。1 つ目の方法は、メソッドをオーバーライドすることです。たとえば、Page オブジェクトの OnLoad メソッドをオーバーライドして、ページ読み込みイベントのコードを記述できます (確実にすべてのイベントを発生させるために、必ず基本メソッドを呼び出してください)。2 つ目の方法は、Visual Basic では Handles キーワードを使用し、C# ではデリゲートワイヤアップを使用して、ページイベントにバインドすることです。
- 要求を処理するパイプラインから未使用のモジュールを削除する。 既定では、Web サーバーコンピュータの Machine.config ファイルで、HttpModules ノード内のすべての機能がアクティブのままになります。アプリケーションで使用する機能に応じて、要求パイプラインから不要なモジュールを削除すると、パフォーマンスを多少向上させることができます。各モジュールとその機能を検討し、必要に応じてカスタマイズします。たとえば、アプリケーションでセッション状態や出力キャッシュを使用しない場合は、これらの機能のモジュールを HttpModules リストから削除できます。
Internet Information Services 5.0 上で Web アプリケーションをアウトプロセスで実行する。 既定では、IIS 5.0 上の ASP.NET は、アウトプロセスワーカープロセスを使用して要求に対応します。この機能は、高速スループットを実現するように調整されています。ASP.NET をアウトプロセスワーカープロセスで実行することによって、その機能や利点が得られるため、実行用のサイトではこの方法をお勧めします。
定期的にプロセスをリサイクルする。 安定性とパフォーマンスの両方を保つために、プロセスは定期的にリサイクルしてください。長時間が経過すると、メモリリークやバグのあるリソースにより Web サーバーのスループットが低下します。プロセスをリサイクルすることで、メモリのこのような問題を一掃できます。ただし、定期的なリサイクルの必要性とリサイクルの頻度とのバランスを取る必要があります。ワーカープロセスの停止、ページの再読み込み、およびリソースやデータの再取得による負荷が、リサイクルによる利点を上回る可能性があるためです。

Windows Server 2003 と IIS 6.0 の環境で動作する ASP.NET Web アプリケーションでは、IIS 6.0 のプロセスモデルの設定が ASP.NET で使用されるため、プロセスモデルを調整する必要はありません。

アプリケーションのワーカープロセスごとのスレッド数を適切に設定する。 ASP.NET の要求アーキテクチャは、要求を実行しているスレッド数と使用可能なリソースのバランスを取ろうとします。このアーキテクチャにより、CPU で処理できる数の同時実行要求のみが実行されるようになります。この手法をスレッドゲーティングと呼びます。ただし、スレッドゲーティングが正しく機能しない場合もあります。Windows パフォーマンスモニタでは、ASP.NET Applications パフォーマンスオブジェクトに関連付けられた Pipeline Instance Count パフォーマンスカウンタを使用して、スレッドゲーティングを監視できます。

ASP.NET Web ページが外部リソースを呼び出すとき (データベースにアクセスする場合や XML Web サービス要求を処理する場合など)、一般に、ページ要求は外部リソースが応答するまで停止します。これにより、CPU が他のスレッドの処理に解放されます。他の要求が処理を待っている状態でスレッドプールに空きスレッドができると、待機中の要求の処理が開始されます。その結果、同時実行される要求数と、ASP.NET ワーカープロセスまたはアプリケーションプールの待機スレッド数が増えることがあります。これは、Web サーバーのスループットを低下させ、パフォーマンスに悪影響を及ぼす可能性があります。

このパフォーマンスへの影響を小さくするために、プロセスのスレッド数の制限を手動で設定できます。そのためには、Machine.config ファイルの processModel セクションで、MaxWorkerThreads 属性と MaxIOThreads 属性を変更します。

メモ :
ワーカースレッドは、ASP.NET 要求を処理するために使用されます。IO スレッドは、ファイル、データベース、または ASP.NET Web サービスからのデータを処理するために使用されます。

プロセスモデルの属性に指定する値は、プロセス内で CPU ごとに割り当てられる、それぞれの種類のスレッドの最大数を表します。2 プロセッサのコンピュータでは、最大数は設定値の 2 倍になります。4 プロセッサのコンピュータでは、最大数は設定値の 4 倍になります。既定の設定は、プロセッサが 1 つまたは 2 つのコンピュータに適しています。プロセッサが 3 つ以上のコンピュータでも、プロセス内のスレッド数が 100 ～ 200 に達するとパフォーマンスが低下する可能性があります。プロセス内のスレッド数が多すぎると、処理速度は低下します。この場合、サーバーでは余分なコンテキスト切り替えが発生し、オペレーティングシステムは要求の処理よりもスレッドの管理に CPU サイクルを費やすことになります。適切なスレッド数は、アプリケーションのパフォーマンスをテストして決定することをお勧めします。

外部リソースに大きく依存するアプリケーションでは、マルチプロセッサコンピュータ上で Web ガーデンを有効にする。 ASP.NET プロセスモデルでは、処理を複数のプロセスに分散することにより、マルチプロセッサコンピュータのスケーラビリティを有効に利用できます。CPU ごとに 1 つのプロセスが割り当てられ、それぞれのプロセッサの関係が CPU に設定されます。この方法は、Web ガーデンと呼ばれることもあります。Web アプリケーションが外部リソースを頻繁に使用する場合は、Web ガーデンから恩恵を得ることができます。たとえば、アプリケーションがデータベースサーバーを使用する場合や、外部の依存関係を持つ COM オブジェクトを呼び出す場合に役立ちます。ただし、実際に運用する Web サイトで Web ガーデンを有効にする前に、Web ガーデンでの Web アプリケーションのパフォーマンスをテストしてください。

コーディングの技法

次のガイドラインでは、効率的なコードを記述するための推奨方法を示します。

例外に依存するコードは記述しない。 例外が発生すると、パフォーマンスが著しく低下する可能性があります。そのため、例外を使用して標準プログラムフローを制御することは避けてください。可能であれば、例外の原因となる条件を検出して対応するロジックをコードに含めます。例外をコードで検出する一般的なシナリオとして、null をチェックしたり、文字列を数値して解析したり、数値演算の前に特定の値をチェックしたりする処理があります。次の例は、例外が発生する可能性のあるコードと、条件をテストして例外を回避するコードを示しています。どちらも結果は同じになります。
```
// This is not recommended.
try {
   result = 100 / num;
}
catch (Exception e) {
  result = 0;
}

// This is preferred.
if (num != 0)
   result = 100 / num;
else
  result = 0;
```
```
' This is not recommended.
Try
   result = 100 / num
Catch (e As Exception)
  result = 0
End Try

' This is preferred.
If Not (num = 0)
   result = 100 / num
Else
  result = 0
End If
```