ASP 開発者は、設計プロジェクトのパフォーマンスとスケーラビリティを向上させるために継続的に努力しています。幸いなことに、この分野に関して優れたアドバイスを提供する書籍やサイトがたくさんあります。ただし、これらの提案は ASP プラットフォームの動作の構造から導き出された結論に基づいており、実際のパフォーマンスの向上を定量的に測定したものではありません。これらの推奨事項では、より複雑なコーディングが必要になり、コードが読みにくくなるため、開発者は、実際の結果を見ることなく、ASP アプリケーションのパフォーマンスを向上させることにコストを払う価値があるかどうかを検討する必要があります。
この記事は 2 つの部分に分かれており、開発者が特定の取り組みが将来のプロジェクトだけでなく、元のプロジェクトを更新する価値があるかどうかを判断するのに役立つように、パフォーマンス テストの結果をいくつか紹介します。最初の部分では、ASP 開発の基本的な問題をいくつか確認します。 2 番目の部分では、いくつかの ADO 関数の最適化と、その結果を VB COM オブジェクトを呼び出して同じ ADO 関数を実行する ASP ページと比較する方法について説明します。その結果は目を見張るものであり、時には驚くべきものです。
この記事では、次の質問に答えます。
* ASP で生成されたコンテンツを応答ストリームに書き込む最も効率的な方法は何ですか?
* バッファを有効にする必要がありますか?
* ASP コードにコメントを追加することを検討すべきですか?
* デフォルト言語をページに明示的に設定する必要がありますか?
* 必要がない場合、セッション状態を閉じる必要がありますか?
* スクリプトロジックはサブルーチンや関数領域に配置する必要がありますか?
* インクルード ファイルを使用するとどのような影響がありますか?
※エラー処理を行う際にどのような負荷がかかりますか?
* コンテキスト ハンドラーのセットアップはパフォーマンスに影響しますか?
すべてのテストは、Microsoft の Web Application Focus Tool (WAST) を使用して実施されました。このツールは、ここから入手できます。 WAST を使用して、以下に説明する ASP ページ テストを繰り返し (それぞれ 70,000 回以上) 呼び出す簡単なテスト スクリプトを作成しました。応答時間は、平均合計最終バイト時間 (TTLB) に基づいています。これは、最初の要求の時刻からツールがサーバーからデータの最後のビットを受信するまでの時間です。私たちのテストサーバーは 196MB の RAM を搭載した Pentium 166 で、クライアントは 256MB の RAM を搭載した Pentium 450 です。これらのマシンのパフォーマンスはそれほど高度ではないと思われるかもしれませんが、忘れないでください。サーバーの容量をテストしているのではなく、サーバーが一度に 1 ページを処理するのにかかる時間をテストしているだけです。テスト中、マシンは他の作業を行いません。 WAST テスト スクリプト、テスト レポート、およびすべての ASP テスト ページは、自分で確認してテストできるように ZIP ファイルに含まれています。
ASP で生成されたコンテンツを応答ストリームに書き込む最も効率的な方法は何ですか?
ASP を使用する最大の理由の 1 つは、サーバー上で動的コンテンツを生成することです。したがって、テストの当然の開始点は、動的コンテンツを応答ストリームに送信する最も適切な方法を決定することです。多くのオプションの中で、最も基本的なオプションは 2 つです。1 つはインライン ASP タグを使用する方法で、もう 1 つは Response.Write ステートメントを使用する方法です。
これらのオプションをテストするために、いくつかの変数を定義し、その値をテーブルに挿入する単純な ASP ページを作成しました。このページはシンプルであまり実用的ではありませんが、いくつかの個別の問題を切り分けてテストすることができます。
ASP インライン タグの使用
最初のテストでは、インライン ASP タグ < %= x % > を使用します。ここで、x は割り当てられた変数です。この方法は実行が最も簡単で、ページの HTML 部分を読みやすく維持しやすい形式に保ちます。
<% オプション明示的
ディム名
ディム姓
ディムミドルイニシャル
ディムアドレス
ディムシティ
薄暗い状態
DimPhoneNumber
薄暗い FAX番号
薄暗いメール
ディム誕生日
名 = ジョン
ミドルイニシャル = Q
姓 = 公開
住所 = 100 メインストリート
都市=ニューヨーク
州=ニューヨーク
電話番号 = 1-212-555-1234
ファックス番号 = 1-212-555-1234
電子メール = [email protected]
生年月日 = 1950/1/1
%>
<HTML>
<頭>
< TITLE >応答テスト < / TITLE >
< /HEAD >
<ボディ>
< H1 >応答テスト < /H1 >
<表>
< tr >< td >< b >名:< /b >< /td >< td >< %= 名 % >< /td >< /tr >
< tr >< td >< b >ミドルイニシャル:< /b >< /td >< td >< %= ミドルイニシャル % >< /td >< /tr >
< tr >< td >< b >姓:< /b >< /td >< td >< %= LastName % >< /td >< /tr >
< tr >< td >< b >アドレス:< /b >< /td >< td >< %= アドレス % >< /td >< /tr >
< tr >< td >< b >都市:< /b >< /td >< td >< %= 都市 % >< /td >< /tr >
< tr >< td >< b >状態:< /b >< /td >< td >< %= 状態 % >< /td >< /tr >
< tr >< td >< b >電話番号:< /b >< /td >< td >< %= PhoneNumber % >< /td >< /tr >
< tr >< td >< b >ファクス番号:< /b >< /td >< td >< %= FAX番号 % >< /td >< /tr >
< tr >< td >< b >メール:< /b >< /td >< td >< %= メール % >< /td >< /tr >
< tr >< td >< b >生年月日:< /b >< /td >< td >< %= 生年月日 % >< /td >< /tr >
< /TABLE >
< /BODY >
< /HTML >
/app1/response1.asp の完全なコード
過去最高(応答速度) = 8.28ミリ秒/ページ
HTML の各行で Response.Write ステートメントを使用します。
より優れた学習ドキュメントの多くでは、前の方法を避けることを推奨しています。その主な理由は、ページを出力してレイテンシーを課すページを処理するプロセスで、Web サーバーがプレーン HTML の送信とスクリプトの処理の間で変換を行う必要がある場合、コンテキスト スイッチングと呼ばれる問題が発生するためです。これを聞くと、ほとんどのプログラマは最初に、生の HTML の各行を Response.Write 関数でラップするでしょう。
…
Response.Write(<html>)
Response.Write(<先頭>)
Response.Write(<title>レスポンステスト</title>)
Response.Write(</head>)
Response.Write(<本文>)
Response.Write(<h1>レスポンステスト</h1>)
Response.Write(<テーブル>)
Response.Write(< tr >< td >< b >名:< /b >< /td >< td > & 名 & < /td >< /tr >)
Response.Write(< tr >< td >< b >ミドルイニシャル:< /b >< /td >< td > & MiddleInitial & < /td >< /tr >)
… <
/app1/response2.asp のフラグメント
過去最高(応答速度) = 8.28ミリ秒/ページ
応答時間 = 8.08 ミリ秒/ページ
差 = -0.20 ミリ秒 (2.4% 削減)
このアプローチを使用した場合のパフォーマンスの向上は、インライン マークアップを使用した場合に比べて非常に小さいことがわかります。これはおそらく、ページが多数の小さな関数呼び出しでサーバーをロードするためです。このアプローチの最大の欠点は、HTML がスクリプトに埋め込まれるため、スクリプト コードがより冗長になり、読み取りや保守が困難になることです。
ラッパー関数を使用する
おそらく、Response.Write ステートメントのアプローチを使用しようとするときに最も気が滅入る発見は、Response.Write 関数が各行の末尾に CRLF を配置できないことです。そのため、ブラウザからソース コードを読み取ると、完璧にレイアウトされていた HTML が、終わりのない 1 行になります。次の発見はさらに恐ろしいものになるかもしれません。Response オブジェクトには姉妹関数 Writeln がありません。したがって、当然の対応策は、Response.Write 関数のラッパー関数を作成して、各行に CRLF を追加することです。
…
writeCR(< tr >< td >< b >名:< /b >< /td >< td > & 名 & < /td >< /tr >)
…
SUB writeCR(str)
Response.Write(str & vbCRLF)
エンドサブ
/app1/response4.asp のフラグメント
過去最高(応答速度) = 8.08ミリ秒/ページ
応答時間 = 10.11 ミリ秒/ページ
差 = +2.03 ミリ秒 (25.1% 増加)
もちろん、このアプローチでは関数呼び出しの数が事実上 2 倍になるため、パフォーマンスへの影響は大きく、絶対に回避する必要があります。皮肉なことに、CRLF はまた、ブラウザーがページにレンダリングする必要のないリアクティブ ストリームに 1 行あたり 2 バイトを追加します。適切にフォーマットされた HTML は、競合他社が HTML ソース コードを読み、デザインを理解しやすくするだけです。
連続する Response.Write を 1 つのステートメントに連結します
ラッパー関数を使用した以前のテストに関係なく、次の論理的なステップは、個別の Response.Write ステートメントからすべての文字列を抽出し、それらを 1 つのステートメントに連結することです。これにより、関数呼び出しの数が減り、ページのパフォーマンスが大幅に向上します。
…
Response.Write(<html>&_
<頭>&_
<title>応答テスト</title> & _
< /head > & _
<本文> & _
< h1 >応答テスト< /h1 > & _
<テーブル>&_
< tr >< td >< b >名:< /b >< /td >< td > & 名 & < /td >< /tr > & _
…
< tr >< td >< b >生年月日:< /b >< /td >< td > & BirthDate & < /td >< /tr > & _
< /table > & _
< /body > & _
< /html >)
/app1/response3.asp のフラグメント
過去最高(応答速度) = 8.08ミリ秒/ページ
応答時間 = 7.05 ミリ秒/ページ
差 = -1.03 ミリ秒 (12.7% 削減)
現時点では、これが最も最適化された構成です。
連続する Response.Write を 1 つのステートメントに連結し、各行の末尾に CRLF を追加します。
ソース コードがブラウザから見て元の状態に見えることを必要とするユーザーを考慮して、前のテストでは vbCRLF 定数を使用して各行の末尾にキャリッジ リターンを挿入し、テストを再実行しました。
…
Response.Write(<html>&vbCRLF&_
<頭> & vbCRLF & _
< title >応答テスト< /title > & vbCRLF & _
< /head > & vbCRLF & _
…
/app1/response5.asp のフラグメント
過去最高 (応答速度) = 7.05 ミリ秒/ページ
応答時間 = 7.63 ミリ秒/ページ
差 = +0.58 ミリ秒 (8.5% 増加)
その結果、おそらく追加の連結と文字数の増加により、パフォーマンスがわずかに低下します。
レビューと観察
ASP 出力に対する以前のテストから、いくつかのルールを導き出すことができます。
* インライン ASP の過度の使用は避けてください。
* 連続する Response.Write ステートメントは常に 1 つのステートメントに連結してください。
* CRLF を追加するために、Response.Write の周囲にラッパー関数を使用しないでください。
* HTML 出力をフォーマットする必要がある場合は、Response.Write ステートメント内に CRLF を直接追加します。
バッファを有効にする必要がありますか?
スクリプト経由でバッファを開始
ASP スクリプトの先頭に Response.Buffer=True を含めることで、IIS はページのコンテンツをキャッシュします。
<% オプション明示的
応答.バッファ = true
ディム名
…
/app1/buffer__1.asp のフラグメント
以前の最高 (応答時間) = 7.05 ミリ秒/ページ
応答時間 = 6.08 ミリ秒/ページ
差 = -0.97 ミリ秒 (13.7% 削減)
パフォーマンスが大幅に向上しました。でも待ってください、もっと良いものがあります。
サーバー構成による開始バッファー
IIS 5.0 ではバッファーがデフォルトで有効になっていますが、IIS 4.0 では手動で有効にする必要があります。次に、サイトの [プロパティ] ダイアログ ボックスを見つけて、 [ホーム ディレクトリ] タブから [構成] ボタンを選択します。次に、「アプリオプション」で「バッファリングを有効にする」を選択します。このテストでは、Response.Buffer ステートメントがスクリプトから移動されました。
以前の最高 = 7.05 ミリ秒/ページ
応答時間 = 5.57 ミリ秒/ページ
差 = -1.48 ミリ秒 (21.0% 削減)
現時点では、これは当社がこれまでに達成した最速の応答であり、以前の最良の場合の応答時間より 21% 短縮されています。今後のテストでは、この反応時間をベースライン値として使用します。
レビューと観察
バッファはパフォーマンスを向上させる優れた方法であるため、バッファをサーバーのデフォルト値に設定することが必要です。何らかの理由でページがバッファを適切に実行できない場合は、Response.Buffer=False コマンドを使用してください。バッファーの欠点の 1 つは、ページ全体が処理されるまでユーザーにはサーバーから何も表示されないことです。したがって、複雑なページの処理中に、時々 Response.Flush を呼び出してユーザーを更新することをお勧めします。
ここで、もう 1 つのルールが追加されました。「サーバー設定によって常にバッファリングを有効にする」というものです。
ASP コードにコメントを追加することを検討すべきですか?
ほとんどの HTML 開発者は、HTML コメントを含めることは悪い考えであることを知っています。第一に、転送されるデータのサイズが増加し、第二に、ページの構成に関する情報を他の開発者に提供するだけです。では、ASP ページ上のコメントはどうなるでしょうか?これらはサーバーから離れることはありませんが、ページのサイズが増加するため、ASP を使用して分割する必要があります。
このテストでは、それぞれ 80 文字のコメントを 20 個追加し、合計 1,600 文字になりました。
<% オプション明示的
'------------------------------------------------ - ---------------------------------
…20行…
'------------------------------------------------ - ---------------------------------
ディム名
…
/app2/comment_1.asp フラグメント
ベースライン = 5.57 ミリ秒/ページ
応答時間 = 5.58 ミリ秒/ページ
差 = +0.01 ミリ秒 (0.1% 増加)
テストの結果は驚くべきものでした。コメントはファイル自体のほぼ 2 倍の長さですが、コメントの存在は応答時間に大きな影響を与えません。したがって、次のルールに従うことができます。
適度に使用されている限り、ASP アノテーションはパフォーマンスにほとんど、またはまったく影響を与えません。
デフォルト言語をページに明示的に設定する必要がありますか?
IIS はデフォルトで VBScript を処理しますが、ほとんどの場合、<%@LANGUAGE=VBSCRIPT%> ステートメントを使用して言語が明示的に VBScript に設定されていることがわかります。次のテストでは、この宣言の存在がパフォーマンスにどのような影響を与えるかを調べます。
< %@ LANGUAGE=VBSCRIPT % >
<% オプション明示的
ディム名
…
/app2/ language1.asp フラグメント。
ベースライン = 5.57 ミリ秒/ページ
応答時間 = 5.64 ミリ秒/ページ
差 = +0.07 ミリ秒 (1.2% 増加)
ご覧のとおり、言語宣言を含めることはパフォーマンスにわずかな影響を与えます。したがって:
* サーバーのデフォルトの言語構成を、サイトで使用されている言語と一致するように設定します。
* デフォルト以外の言語を使用する場合を除き、言語宣言を設定しないでください。
必要がない場合、セッション状態をオフにする必要がありますか?
IIS セッション コンテキストの使用を避ける理由は数多くありますが、それらは独自の記事である可能性があります。私たちが今答えようとしている疑問は、ページが必要としないときにセッション コンテキストを閉じることがパフォーマンスの向上に役立つかどうかです。理論的には、セッション コンテキストをインスタンス化するためにページを使用する必要がないため、これは [はい] になるはずです。
バッファと同様に、セッション状態を構成するには、スクリプトを使用する方法とサーバー設定を使用する方法の 2 つがあります。
スクリプト経由でセッションコンテキストを閉じる
このテストでは、ページ内のセッション コンテキストを閉じるために、セッション状態宣言を追加しました。
< %@ ENABLESESSIONSTATE = FALSE % >
<% オプション明示的
ディム名
…
/app2/session_1.asp フラグメント。
ベースライン = 5.57 ミリ秒/ページ
応答時間 = 5.46 ミリ秒/ページ
差 = -0.11 ミリ秒 (2.0% 減少)
このような小さな努力によって、大きな進歩が見られました。次にパート 2 を見てください。
サーバー設定を通じてセッションコンテキストを閉じます
サーバー上のセッション コンテキストを閉じるには、サイトの [プロパティ] ダイアログ ボックスに移動します。 [ホーム ディレクトリ] タブの [構成] ボタンを選択します。次に、「アプリオプション」で「セッション状態を有効にする」のチェックを外します。 ENABLESESSIONSTATE ステートメントを使用せずにテストを実行します。
ベースライン = 5.57 ミリ秒/ページ
応答時間 = 5.14 ミリ秒/ページ
差 = -0.43 ミリ秒 (7.7% 削減)
これもパフォーマンスの大幅な向上です。したがって、私たちのルールは次のようにする必要があります: セッション状態が必要でない場合は、ページまたはアプリケーション レベルで常にセッション状態を閉じる必要があります。
Option Explicit を使用するとパフォーマンスが大幅に変わりますか?
ASP ページの先頭で Option Explicit を設定すると、使用前にページ上ですべての変数を宣言する必要があります。これには 2 つの理由があります。まず、アプリケーションは変数アクセスをより高速に処理できます。第 2 に、これにより変数名を誤って使用することが防止されます。このテストでは、変数の Option Explicit 参照と Dim 宣言を削除します。
ベースライン = 5.57 ミリ秒/ページ
応答時間 = 6.12 ミリ秒/ページ
差 = +0.55 ミリ秒 (9.8% 増加)、
いくつかのコード行がページから削除されたにもかかわらず、応答時間は依然として増加しました。そのため、明示的なオプションの使用には時間がかかる場合がありますが、パフォーマンスに大きな影響を与えます。そこで、別のルールを追加できます。つまり、VBScript では常に Option を明示的に使用します。
スクリプトロジックはサブルーチンや関数領域に配置する必要がありますか?
関数とサブルーチンの使用は、特にコード領域がページ上で複数回使用される場合に、コードを編成および管理するための良い方法です。欠点は、同じジョブを実行するシステムに追加の関数呼び出しが追加されることです。サブルーチンと関数に関するもう 1 つの問題は、変数のスコープです。理論的には、関数領域内で変数を指定する方が効率的です。次に、これら 2 つの側面がどのように影響するかを見てみましょう。
Response.Write ステートメントをサブルーチンに移動します。
このテストは、Response.Write ステートメントをサブルーチン領域に移動するだけです。
…
writeTable() を呼び出す
SUB writeTable()
Response.Write(<html>&_
<頭>&_
…
< tr >< td >< b >メール:< /b >< /td >< td > & メール & < /td >< /tr > & _
< tr >< td >< b >生年月日:< /b >< /td >< td > & BirthDate & < /td >< /tr > & _
< /table > & _
< /body > & _
< /html >)
エンドサブ
/app2/function1.asp フラグメント
ベースライン = 5.57 ミリ秒/ページ
応答時間 = 6.02 ミリ秒/ページ
差 = +0.45 ミリ秒 (8.1% 増加)
予想どおり、サブルーチン呼び出しによりページに追加のオーバーヘッドが発生します。
すべてのスクリプトをサブルーチンに移動します
このテストでは、Response.write ステートメントと変数宣言がサブルーチン領域に移動されます。
<% オプション明示的
writeTable() を呼び出す
SUB writeTable()
ディム名
…
ディム誕生日
名 = ジョン
…
生年月日 = 1950/1/1
Response.Write(<html>&_
<頭>&_
<title>応答テスト</title> & _
< /head > & _
<本文> & _
< h1 >応答テスト< /h1 > & _
<テーブル>&_
< tr >< td >< b >名:< /b >< /td >< td > & 名 & < /td >< /tr > & _
…
< tr >< td >< b >生年月日:< /b >< /td >< td > & BirthDate & < /td >< /tr > & _
< /table > & _
< /body > & _
< /html >)
エンドサブ
/app2/function2.asp フラグメント
ベースライン = 5.57 ミリ秒/ページ
応答時間 = 5.22 ミリ秒/ページ
差 = -0.35 ミリ秒 (6.3% 削減)
とても興味深いです!変数を関数スコープに移動すると追加の関数呼び出しが追加されますが、実際にはパフォーマンスが向上します。次のルールを追加できます。
※ページ内でコードを複数回使用する場合は、コードをファンクションエリアで囲んでください。
* 必要に応じて、変数宣言を関数スコープに移動します。
インクルード ファイルを使用するとどのような影響がありますか?
ASP プログラミングの重要な機能は、他のページのコードを組み込めることです。この機能を使用すると、プログラマは複数のページにわたって関数を共有できるため、コードの保守が容易になります。欠点は、サーバーが複数のソースからページを組み立てる必要があることです。以下は、Include ファイルを使用した 2 つのテストです。
インラインコードを使用してファイルをインクルードする
このテストでは、コードの小さな部分がインクルード ファイルに移動されています。
<% オプション明示的
ディム名
…
ディム誕生日
名 = ジョン
…
生年月日 = 1950/1/1
%>
< !-- #include file=inc1.asp -- >
/app2/include_1.asp フラグメント
ベースライン = 5.57 ミリ秒/ページ
応答時間 = 5.93 ミリ秒/ページ
差 = +0.36 ミリ秒 (6.5% 増加)
これは驚くべきことではありません。ペイロードは、インクルード ファイルを使用して形成されます。
関数領域でインクルードファイルを使用する
ここで、コードはインクルード ファイルのサブルーチンにラップされています。 Include 参照はページの上部で作成され、ASP スクリプト内の適切な場所でサブルーチンを呼び出します。
<% オプション明示的
ディム名
…
ディム誕生日
名 = ジョン
…
生年月日 = 1950/1/1
writeTable() を呼び出す
%>
< !-- #include file=inc2.asp -- >
/app2/include_2.asp フラグメント
ベースライン = 5.57 ミリ秒/ページ
応答時間 = 6.08 ミリ秒/ページ
差=+0.51ミリ秒(9.2%増加)
これは、関数呼び出しよりもパフォーマンスに大きな影響を与えます。したがって、コードがページ間で共有される場合にのみ、インクルード ファイルを使用してください。
エラー処理を実行するときにどのくらいの負荷が発生しますか?
エラー処理はすべての実際のアプリケーションに必要です。このテストでは、On Error Resume Next 関数を呼び出すことによってエラー ハンドラーが呼び出されます。
<% オプション明示的
エラー時は次へ再開
ディム名
…
/app2/error_1.asp フラグメント
ベースライン = 5.57 ミリ秒/ページ
応答時間 = 5.67 ミリ秒/ページ
差 = 0.10 ミリ秒 (1.8% 増加)
ご覧のとおり、エラー処理には代償が伴います。次のことをお勧めします。 テストまたは制御の能力を超えた何かが発生した場合にのみ、エラー ハンドルを使用します。基本的な例は、COM オブジェクトを使用して、ADO や FileSystem オブジェクトなどの他のリソースにアクセスすることです。
コンテキスト ハンドラーの設定はパフォーマンスに影響しますか?
エラーが発生した場合、ページにコンテキスト ハンドラーを設定すると、スクリプトでアクションを元に戻すことができます。これは、ページ上の処理ステートメントを使用して設定されます。
< %@ トランザクション = 必須 % >
<% オプション明示的
ディム名
…
/app2/transact1.asp フラグメント
ベースライン = 5.57 ミリ秒/ページ
応答時間 = 13.39 ミリ秒/ページ
差 = +7.82 ミリ秒 (140.4% 増加)
ああ!これはまさに最も劇的な結果です。したがって、次のルールに注意してください。処理コンテキストは、2 つ以上の操作が 1 つの単位として実行される場合にのみ使用します。
結論は
この記事の最初の部分で重要なのは、多くの小さなことの積み重ねです。この問題を強調するために、以前にテストした無害に見えて実際には悪影響を及ぼしたすべてのことを実行する最終テストを設定しました。一連の Response.Write ステートメントを組み込み、バッファーをオフにし、デフォルト言語を設定し、Option Explicit 参照を削除し、エラー ハンドラーを初期化しました。
< %@ LANGUAGE=VBSCRIPT % >
< %
エラー時は次へ再開
名 = ジョン
…
生年月日 = 1950/1/1
Response.Write(<html>)
Response.Write(<先頭>)
Response.Write(<title>レスポンステスト</title>)
Response.Write(</head>)
Response.Write(<本文>)
Response.Write(<h1>レスポンステスト</h1>)
Response.Write(<テーブル>)
Response.Write(< tr >< td >< b >名:< /b >< /td >< td > &_
名 & < /td >< /tr >)
…
Response.Write(< tr >< td >< b >生年月日:< /b >< /td >< td > &_
生年月日 & < /td >< /tr >)
Response.Write(</テーブル>)
Response.Write(</body>)
Response.Write(</html>)
%>
/app2/final_1.asp フラグメント
ベースライン = 5.57 ミリ秒/ページ
応答時間 = 8.85 ミリ秒/ページ
差 = +3.28 ミリ秒 (58.9% 増加)
当たり前のことのように聞こえるかもしれませんが、ページに配置するコードがパフォーマンスに影響を与えることを理解することがより重要です。ページ上の小さな変更により、応答時間が大幅に長くなる場合があります。
ルールの概要
* インライン ASP の過度の使用は避けてください。
* 連続する Response.Write ステートメントは常に 1 つのステートメントに連結してください。
* CRLF を追加するために、Response.Write の周囲にラッパー関数を使用しないでください。
* HTML 出力をフォーマットする必要がある場合は、Response.Write ステートメント内に CRLF を直接追加します。
* サーバー設定でバッファリングを常に有効にします。
* 適度に使用されている限り、ASP アノテーションはパフォーマンスにほとんど、またはまったく影響を与えません。
* サーバーのデフォルトの言語構成を、サイトで使用されている言語と一致するように設定します。
* デフォルト以外の言語を使用する場合を除き、言語宣言を設定しないでください。
* VBScript では常に明示的なオプションを使用してください。
* 必要がない場合は、ページまたはアプリケーション レベルでセッション状態を常にオフにしてください。
* コードがページ間で共有される場合にのみ、インクルード ファイルを使用します。
※ページ内でコードを複数回使用する場合は、コードをファンクションエリアで囲んでください。
* 必要に応じて、変数宣言を関数スコープに移動します。
* エラー ハンドルは、テストまたは制御の能力を超えた状況が発生した場合にのみ使用してください。
※コンテキスト処理は複数の操作を単位として行う場合にのみ使用してください。
今振り返ると、一般的なガイドラインとして役立つ質問がいくつかあります。
* 冗長性を避けてください。デフォルトですでに設定されているプロパティを設定しないでください。
* 関数呼び出しの数を制限します。
* コードの範囲を減らします。