Microsoft が推奨する ASP パフォーマンス最適化のための 28 のルール

パフォーマンスが特徴です。事前にパフォーマンスを考慮して設計する必要があります。そうしないと、後でアプリケーションを書き直す必要があります。そうは言っても、Active Server Pages (ASP) アプリケーションのパフォーマンスを最大化するための優れた戦略は何でしょうか?

この記事では、ASP アプリケーションと Visual Basic® Scripting Edition (VBScript) を最適化する手法について説明します。この記事では、いくつかの落とし穴について説明します。この記事に記載されている提案はhttp://www.microsoft.comおよびその他のサイトでテストされており、その結果は非常に重要です。この記事は、VBScript や JScript、ASP アプリケーション、ASP セッション、その他の ASP 固有オブジェクト (リクエスト、レスポンス、サーバー) などの ASP 開発の基本をすでに理解していることを前提としています。

通常、ASP のパフォーマンスは主に、ASP コード自体以外の多くの要因に依存します。すべての情報を 1 つの記事にリストするのではなく、記事の最後にパフォーマンス関連のリソースをリストします。これらのリンクでは、ActiveX® データ オブジェクト (ADO)、コンポーネント オブジェクト モデル (COM)、データベース、インターネット インフォメーション サーバー (IIS) 構成など、ASP および非 ASP のトピックがカバーされています。これらは私たちのお気に入りのリンクの一部です - ぜひチェックしてください。

ヒント 1: 頻繁に使用するデータを Web サーバーにキャッシュする

一般的な ASP ページは、バックエンド データ ストアからデータを取得し、その結果をハイパーテキスト マークアップ言語 (HTML) に変換します。データベースの速度に関係なく、メモリからのデータの取得は、バックエンド データ ストアからのデータの取得よりも常にはるかに高速です。また、ローカル ハード ドライブからのデータの読み取りは、通常、データベースからデータを取得するよりも高速です。したがって、多くの場合、データを Web サーバーにキャッシュする (メモリまたはディスクに保存する) ことでパフォーマンスを向上させることができます。

キャッシュは、スペースと時間を交換する従来の方法です。適切なコンテンツをキャッシュすると、パフォーマンスが大幅に向上することがわかります。キャッシュを効果的にするには、頻繁に再利用されるデータを保存する必要があり、このデータの再計算には (適度に) 大きなオーバーヘッドが必要です。キャッシュ内のすべてが古いデータである場合、メモリの無駄が発生します。

頻繁に変更されないデータは、長期間にわたってそのデータをデータベースと同期することを心配する必要がないため、キャッシュに適しています。コンボ ボックス リスト、参照テーブル、DHTML フラグメント、拡張マークアップ言語 (XML) 文字列、メニュー項目、サイト構成変数 (データ ソース名 (DSN)、インターネット プロトコル (IP) アドレス、Web パスを含む) はすべて適切なキャッシュです。コンテンツ。データ自体をキャッシュしなくても、データの「表現」をキャッシュできることに注意してください。 ASP ページがめったに変更されず、キャッシュにコストがかかる場合 (製品カタログ全体など)、リクエストに応じて HTML を再表示するのではなく、事前に HTML を生成することを検討する必要があります。

データをどこにキャッシュする必要がありますか?また、どのようなキャッシュ戦略がありますか?通常、データは Web サーバーのメモリまたはディスクにキャッシュされます。次の 2 つのヒントでは、両方の方法について説明します。

ヒント 2: 頻繁に使用されるデータをアプリケーション オブジェクトまたはセッション オブジェクトにキャッシュする

ASP アプリケーション オブジェクトとセッション オブジェクトは、データをメモリにキャッシュするための便利なコンテナーを提供します。データを Application オブジェクトと Session オブジェクトに割り当てることができ、データは HTTP 呼び出し間でメモリ内に残ります。セッション データはユーザーごとに個別に保存されますが、アプリケーション データはすべてのユーザー間で共有されます。

データをアプリケーションまたはセッションにいつロードする必要がありますか?通常、データはアプリケーションまたはセッションの開始時にロードされます。アプリケーションまたはセッションの起動中にデータをロードするには、適切なコードをそれぞれ Application_OnStart() または Session_OnStart() に追加します。これらの関数は Global.asa にある必要がありますが、ない場合は追加できます。このデータは、初めて必要になったときにもロードできます。これを行うには、ASP ページにコードを追加して (または再利用可能なスクリプト関数を作成して)、データが存在するかどうかを確認し、存在しない場合はデータをロードします。これは、「遅延評価」と呼ばれる伝統的なパフォーマンス手法であり、値が必要であることがわかるまで値を計算しません。例:

<%
関数 GetEmploymentStatusList
ディム・ディ
d = アプリケーション(?雇用状況リスト?)
d = ??の場合
' FetchEmploymentStatusList 関数 (表示されていません)
' DB からデータをフェッチし、配列を返します
d = FetchEmploymentStatusList()
Application(?EmploymentStatusList?) = d
終了の場合
GetEmploymentStatusList = d
終了機能
%>
必要なデータ ブロックごとに同様の関数を記述することができます。

データはどのような形式で保存する必要がありますか?すべてのスクリプト変数はバリアント型であるため、任意のバリアント型を保存できます。たとえば、文字列、整数、または配列を保存できます。通常、ADO レコードセットの内容は、これらの変数タイプのいずれかに格納します。 ADO レコードセットからデータを取得するには、一度に 1 フィールドずつ手動でデータを VBScript 変数にコピーします。 ADO レコードセット永続化関数 GetRows()、GetString()、または Save() (ADO 2.5) のいずれかを使用する方が速くて簡単です。詳細についてはこの記事の範囲を超えていますが、GetRows() を使用してレコードセット データの配列を返す関数の例を次に示します。

' Get Recordset, return as an Array
関数 FetchEmploymentStatusList
ディムル
Set rs = CreateObject(?ADODB.Recordset?)
rs.Open ?従業員ステータスからステータス名、ステータスIDを選択?, _
?dsn=従業員;uid=sa;pwd=;?
FetchEmploymentStatusList = rs.GetRows() データを配列として返す
rs.閉じる
Setrs=なし
End Function は、

HTML を配列ではなくリストとしてキャッシュすることで、上記の例をさらに改善します。簡単な例を次に示します:

' レコードセットを取得し、HTML オプション リストとして返します。
関数 FetchEmploymentStatusList
Dim rs、fldName、s
Set rs = CreateObject(?ADODB.Recordset?)
rs.Open ?従業員ステータスからステータス名、ステータスIDを選択?, _
?dsn=従業員;uid=sa;pwd=;?
s = ?<選択名=??雇用状況??> & vbCrLf
Set fldName = rs.Fields(?StatusName?) ' ADO フィールド バインディング
rs.EOFまで行う
' 次の行は文字列連結を行わないでくださいに違反しています。
' でもキャッシュを構築しているので大丈夫です
s = s & ? <オプション>? & vbCrLf
rs.次へ移動
ループ
s = s & ?</select>?
rs.閉じる
Set rs = Nothing ' 早期リリースを参照
FetchEmploymentStatusList = s ' データを文字列として返します
終了機能
適切な条件下では、ADO レコードセット自体をアプリケーション スコープまたはセッション スコープにキャッシュできます。注意点が 2 つあります。ADO

はフリースレッドとしてマークされている必要があり、切断されたレコードセットを使用する必要があります。
これら 2 つの要件が保証されていない場合は、ADO レコードセットをキャッシュしないでください。次の「非アジャイル コンポーネント」および「接続をキャッシュしない」に関するヒントでは、COM オブジェクトをアプリケーション スコープまたはセッション スコープに保存することの危険性について説明します。

データを Application スコープまたは Session スコープに保存すると、プログラムで変更するか、セッションが期限切れになるか、Web アプリケーションが再起動されるまで、データはそこに残ります。データを更新する必要がある場合はどうすればよいですか?アプリケーション データの更新を手動で強制するには、管理者専用の ASP ページにアクセスしてデータを更新できます。あるいは、関数を使用して定期的にデータを自動的に更新することもできます。次の例では、キャッシュされたデータとともにタイムスタンプを保存し、一定期間後にデータを更新します。

<%
' エラー処理が表示されません...
Const UPDATE_INTERVAL = 300 ' 更新間隔 (秒単位)

' 雇用状況リストを返す関数
関数 GetEmploymentStatusList
雇用状況の更新
GetEmploymentStatusList = アプリケーション(?EmploymentStatusList?)
End Function

' キャッシュされたデータを定期的に更新します
サブ更新雇用ステータスリスト
ディム d、strLastUpdate
strLastUpdate = アプリケーション(?LastUpdate?)
If (strLastUpdate = ??) または _
(UPDATE_INTERVAL < DateDiff(?s?, strLastUpdate, Now)) then

' 注: ここでは 2 つ以上の呼び出しが行われる可能性がありますが、これは問題ありません。
' いくつかの不要なフェッチが発生します (これには回避策があります)

' FetchEmploymentStatusList 関数 (表示されていません)
' DB からデータをフェッチし、配列を返します
d = FetchEmploymentStatusList()

' Application.Lock() を使用して Application オブジェクトを更新します。
' データの一貫性を確保するため
アプリケーション.ロック
Application(?EmploymentStatusList?) = イベント
アプリケーション(?LastUpdate?) = CStr(現在)
アプリケーション.ロック解除
終了の場合
エンドサブ
例もある「アプリケーション データを使用した世界最速の ListBox」を参照してください。

Session オブジェクトや Application オブジェクトに大きな配列をキャッシュすることは良い習慣ではないことに注意してください。スクリプト言語の構文では、配列の要素にアクセスする前に、配列全体を一時的にコピーする必要があります。たとえば、米国の郵便番号を地域の気象観測所にマッピングする 100,000 要素の文字列配列を Application オブジェクトにキャッシュする場合、ASP はまず 100,000 の気象観測所をすべて一時配列にコピーする必要があり、その後でのみ文字列を抽出できます。この場合、気象観測所を保存するカスタム メソッドを使用してカスタム コンポーネントを構築するか、辞書コンポーネントを使用する方が良いでしょう。

もう 1 つの警告として、赤ちゃんをお風呂の水と一緒に捨てないでください。配列はすぐに検索され、隣接するキー データ ペアとしてメモリに保存されます。辞書のインデックス付けは、配列のインデックス付けよりもはるかに時間がかかります。状況に応じて最高のパフォーマンスを提供するデータ構造を選択する必要があります。

ヒント 3: データと HTML を Web サーバーのディスクにキャッシュする

場合によっては、データが多すぎてメモリにキャッシュできない場合があります。 「多すぎる」というのは、消費するメモリの量、キャッシュする必要があるアイテムの数とそれらを取得する頻度によって決まるというだけの言い方です。いずれの場合も、データが多すぎてメモリにキャッシュできない場合は、データを Web サーバーのハード ドライブにテキスト ファイルまたは XML ファイルとしてキャッシュすることを検討してください。データをディスクとメモリに同時にキャッシュして、サイトに最適なキャッシュ戦略を確立できます。

単一の ASP ページのパフォーマンスを測定する場合、ディスクからのデータの取得がデータベースからのデータの取得よりも必ずしも高速であるとは限らないことに注意してください。ただし、キャッシュによりデータベースとネットワークの負荷が軽減されます。負荷が高い場合、これにより全体のスループットが大幅に向上します。これは、高価なクエリ (複数テーブル結合や複合ストアド プロシージャなど) や大規模な結果セットの結果をキャッシュする場合に非常に効果的です。いつものように、いくつかのオプションの長所と短所をテストします。

ASP と COM は、ディスクベースのキャッシュ ソリューションをセットアップするためのツールを提供します。 ADO レコードセットの Save() 関数と Open() 関数は、ディスクからレコードセットを保存およびロードします。これらのメソッドを使用すると、Application オブジェクトにコードを書き込む代わりにファイルの Save() を使用して、上記のアプリケーション データ キャッシュ手法のコード例を書き直すことができます。

ファイルを操作するコンポーネントが他にもいくつかあります。

Scripting.FileSystemObject を使用すると、ファイルの作成、読み取り、書き込みができます。
Internet Explorer に付属の Microsoft® XML パーサー (MSXML) は、XML ドキュメントの保存とロードをサポートしています。
LookupTable オブジェクト (MSN などで使用) は、ディスクから単純なリストをロードする場合に最適です。
最後に、データそのものではなく、データ表現をディスク上にキャッシュすることを検討してください。変換前 HTML は、ディスク上の .htm または .asp ファイルに保存でき、ハイパーリンクはこれらのファイルを直接指すことができます。 XBuilder などの商用ツールや Microsoft® SQL Server® Internet Publishing 機能を使用して、HTML 生成プロセスを自動化できます。あるいは、HTML コード スニペットを .asp ファイルに配置することもできます。 FileSystemObject を使用してディスクから HTML ファイルを読み取ることも、XML を使用してそれらを早期に変換することもできます。

ヒント 4: アプリケーション オブジェクトまたはセッション オブジェクトに非アジャイル コンポーネントをキャッシュしないようにする

アプリケーション オブジェクトまたはセッション オブジェクトにデータをキャッシュすることは良い習慣ですが、COM オブジェクトのキャッシュには重大な落とし穴があります。通常、頻繁に使用される COM オブジェクトを Application オブジェクトまたは Session オブジェクトにキャッシュする傾向があります。残念ながら、多くの COM オブジェクト (Visual Basic 6.0 以前で記述されたすべてのオブジェクトを含む) は、Application オブジェクトまたは Session オブジェクトに格納されると深刻なボトルネックを引き起こします。

具体的には、非アジャイル コンポーネントがセッション オブジェクトまたはアプリケーション オブジェクトにキャッシュされると、パフォーマンスのボトルネックが発生します。アジャイル コンポーネントは、ThreadingModel= Both とマークされたコンポーネントであり、フリー スレッド マーシャラー (FTM) を集約するか、ThreadingModel=Neutral とマークされたコンポーネントです。 (ニュートラル モデルは、Windows® 2000 および COM+ 用の新機能です。) 次のコンポーネントは機敏ではありません:

フリー スレッド コンポーネント (FTM を集約しない限り)。
アパートメントのスレッドコンポーネント。
シングルスレッドコンポーネント。
構成されたコンポーネント (Microsoft Transaction Server (MTS)/COM+ ライブラリおよびサーバー パッケージ/アプリケーション) は、ニュートラル スレッドでない限り機敏ではありません。アパートメント スレッド コンポーネントおよびその他の非アジャイル コンポーネントは、ページ スコープで最も適しています (つまり、単一の ASP ページ上で作成および破棄されます)。

IIS 4.0 では、ThreadingModel= Both とマークされたコンポーネントはアジャイルとみなされます。 IIS 5.0 では、これだけでは十分ではありません。コンポーネントは Both とマークされるだけでなく、集約 FTM である必要もあります。アジリティに関する記事では、アクティブ テンプレート ライブラリで記述された C++ コンポーネントを使用して FTM を集約する方法について説明します。コンポーネントがインターフェイス ポインターをキャッシュする場合、それらのポインター自体が機敏であるか、COM 共通インターフェイス テーブル (GIT) に格納されている必要があることに注意してください。 Both スレッド コンポーネントを再コンパイルして FTM を集約できない場合は、そのコンポーネントに ThreadingModel=Neutral のマークを付けることができます。あるいは、IIS でアジリティ チェックを実行したくない場合 (したがって、非アジャイル コンポーネントをアプリケーション スコープまたはセッション スコープに格納できるようにすることができます)、メタベースで AspTrackThreadingModel を True に設定できます。 AspTrackThreadingModel を変更することはお勧めできません。

Server.CreateObject で作成された非アジャイル コンポーネントを Application オブジェクトに保存する場合、IIS 5.0 はエラーをスローします。 Global.asa で <object runat=serverscope=application ...> を使用することでこのエラーを回避できますが、以下で説明するプーリングとシリアル化が発生する可能性があるため、これはお勧めできません。

非アジャイルコンポーネントをキャッシュするとどうなるでしょうか? Session オブジェクトにキャッシュされた非アジャイル コンポーネントは、セッションを ASP ワーカー スレッドにロックします。 ASP は、リクエストを処理するためにワーカー スレッドのプールを維持します。通常、新しいリクエストは常に最初に使用可能なワーカー スレッドによって処理されます。セッションがスレッドにロックされている場合、リクエストは、関連付けられたスレッドが使用可能になるまで待機する必要があります。これは役に立つかもしれない例えです。あなたはスーパーマーケットに行き、いくつかの商品を選び、チェックアウト カウンター #_3 で支払います。それ以降、そのスーパーマーケットで商品の代金を支払うときは、たとえ他のレジの列が少ないかまったくない場合でも、常にチェックアウト #_3 で支払う必要があります。

非アジャイル コンポーネントをアプリケーション スコープに保存すると、パフォーマンスにさらに悪影響が生じます。 ASP は、アプリケーション スコープに格納されている非アジャイル コンポーネントを実行するための特別なスレッドを作成する必要があります。これには 2 つの影響があります。すべての呼び出しがこのスレッドに集中される必要があることと、すべての呼び出しがキューに入れられることです。 「プーリング」とは、パラメータをメモリの共有領域に保存する必要があること、コンポーネントのメソッドを実行して結果を共有領域にプールすること、および制御を返すことを意味します。元のスレッドへ。 「シリアル化」とは、一度に 1 つのメソッドだけが実行されることを意味します。 2 つの異なる ASP ワーカー スレッドは、共有コンポーネント上で複数のメソッドを同時に実行できません。これにより、特にマルチプロセッサ コンピュータでの同時実行性が排除されます。さらに悪いことに、アジャイル アプリケーションをスコープとしないすべてのコンポーネントは単一のスレッド (ホスト STA) を共有するため、シリアル化の影響はさらに大きくなります。

私に何ができる？ここでは一般的なルールをいくつか示します。 Visual Basic (6.0) 以前を使用してオブジェクトを作成する場合は、それらを Application オブジェクトまたは Session オブジェクトにキャッシュしないでください。オブジェクトのスレッド モデルがわからない場合は、キャッシュしないでください。非アジャイル オブジェクトはキャッシュせず、各ページで作成してリリースします。オブジェクトは ASP ワーカー スレッド上で直接実行されるため、プールやシリアル化は行われません。 COM オブジェクトが IIS サーバー上で実行されている場合、初期化と削除に長い時間がかからなければ、パフォーマンスは許容範囲内です。シングルスレッドのオブジェクトはこの方法で使用しないでください。注意してください - VB はシングルスレッドのオブジェクトを作成できます。このようにシングルスレッド オブジェクト (Microsoft Excel スプレッドシートなど) を使用する必要がある場合は、高いスループットを期待しないでください。

ADO がフリースレッドとしてマークされている場合、ADO レコードセットを安全にキャッシュできます。 ADO をフリースレッドとしてマークするには、Makfre15.bat ファイルを使用します。このファイルは通常、ディレクトリ\Program FilesCommonSystemADO にあります。

警告 Microsoft Access をデータベースとして使用する場合は、ADO をフリースレッドとしてマークしないでください。 ADO レコードセットも切断する必要があります。一般に、サイト内の ADO 構成を制御しない場合 (たとえば、独自の構成を管理する顧客に Web アプリケーションを販売する独立系ソフトウェア ベンダー (ISV) の場合)、レコードセットをキャッシュしないことをお勧めします。

辞書コンポーネントもアジャイル オブジェクトです。 LookupTable はデータ ファイルからデータをロードし、コンボ ボックス データと構成情報に使用できます。 Duwamish Books の PageCache オブジェクトは、Caprock Dictionary と同様に辞書構文を提供します。これらのオブジェクトまたはその派生オブジェクトは、効果的なキャッシュ戦略の基礎を形成できます。 Scripting.Dictionary オブジェクトは機敏ではないため、Application スコープまたは Session スコープに保存しないでください。

ヒント 5: データベース接続をアプリケーション オブジェクトまたはセッション オブジェクトにキャッシュしないでください

。ADO 接続をキャッシュすることは、一般に不適切な戦略です。 Connection オブジェクトが Application オブジェクトに保存され、すべてのページで使用される場合、すべてのページがこの接続を求めて競合します。 Connection オブジェクトが ASP Session オブジェクトに格納されている場合、ユーザーごとにデータベース接続が作成されます。これにより、接続プーリングの利点が無効になり、Web サーバーとデータベースに不必要な負荷がかかります。

データベース接続をキャッシュする代わりに、ADO を使用する各 ASP ページで ADO オブジェクトを作成および削除できます。 IIS にはデータベース接続プーリングが組み込まれているため、これは効率的です。より正確に言うと、IIS は OLEDB および ODBC 接続プーリングを自動的に有効にします。これにより、すべてのページで作成および削除された接続が有効になることが保証されます。

接続されたレコードセットにはデータベース接続への参照が保存されるため、接続されたレコードセットを Application オブジェクトまたは Session オブジェクトにキャッシュしないでください。ただし、データ接続への参照を保持しない、切断されたレコードセットを安全にキャッシュできます。レコードセットを切断するには、次の 2 つの手順を実行します。

Set rs = Server.CreateObject(?ADODB.RecordSet?)
rs.CursorLocation = adUseClient 'ステップ 1

' レコードセットにデータを設定します
rs.Open strQuery, strProv

' データ プロバイダーとデータ ソースからレコードセットを切断します
rs.ActiveConnection = なし ' ステップ 2
接続プーリングの詳細については、ADO および SQL Server の参考資料を参照してください。

ヒント 6: Session オブジェクトを適切に使用する

アプリケーションとセッションでのキャッシュの利点について説明しました。次に、Session オブジェクトの使用を回避する方法について説明します。以下で説明するように、Session をビジーなサイトで使用すると、いくつかの欠点があります。 「ビジー」とは通常、1 秒あたり数百ページ、または数千人の同時ユーザーを必要とするサイトを意味します。このヒントは、水平方向に拡張する必要があるサイト、つまり、負荷の処理やフォールト トレランスの実現に複数のサーバーを利用するサイトではさらに重要です。イントラネット サイトなどの小規模なサイトで、Session によってもたらされる利点を実現したい場合、システムのオーバーヘッドが必然的に増加します。

つまり、ASP は Web サーバーにアクセスするユーザーごとにセッションを自動的に作成します。各セッションには約 10 KB のメモリ オーバーヘッドが必要であり (主に、データがセッションに保存されるため)、すべてのリクエストが遅くなります。セッションは、設定されたタイムアウト期間 (通常は 20 分) が経過するまで有効です。

Session の最大の問題はパフォーマンスではなく、スケーラビリティです。セッションが複数の Web サーバーにまたがることはできません。セッションが 1 つのサーバー上に作成されると、そのデータはそこに残ります。つまり、Web サーバー ファームでセッションを使用する場合は、ユーザーのセッションが存在するサーバーに各ユーザー要求を常に送信するポリシーを設計する必要があります。これは、ユーザーを Web サーバーに「接着」することと呼ばれます。 「スティッキーセッション」という用語はこれに由来しています。 Web サーバーがクラッシュすると、セッションはディスクに固定されていないため、「固定」ユーザーはセッション状態を失います。

スティッキー セッションを実現するための戦略には、ハードウェア ソリューションとソフトウェア ソリューションが含まれます。 Windows 2000 Advanced Server のネットワーク負荷分散や Cisco の Local Director などのソリューションでは、ある程度のスケーラビリティを犠牲にしてスティッキー セッションを実装できます。これらの解決策は不完全です。現時点では、独自のソフトウェア ソリューションを展開することはお勧めできません (以前は ISAPI フィルターや URL 変換などを使用していました)。

また、アプリケーション オブジェクトは複数のサーバーにまたがることはありません。Web サーバーのファーム全体でアプリケーション データを共有および更新する必要がある場合は、バックエンド データベースを使用する必要があります。ただし、読み取り専用のアプリケーション データは Web サーバー ファームで引き続き役立ちます。

ほとんどのミッションクリティカルなサイトでは、(フェイルオーバーやサーバーのメンテナンスを処理するため) 稼働時間を増やすためだけでも、少なくとも 2 台の Web サーバーが必要です。したがって、ミッション クリティカルなアプリケーションを設計する場合は、「スティッキー セッション」を実装するか、単一の Web サーバーにユーザー状態を保存するセッションやその他の状態管理テクノロジの使用を避ける必要があります。

セッションを使用していない場合は、必ずセッションを閉じてください。これは、インターネット サービス マネージャーを通じてアプリケーションに対して実行できます (ISM ドキュメントを参照)。セッションを使用することに決めた場合、パフォーマンスへの影響を軽減できる方法があります。

セッションを必要としないコンテンツ (ヘルプ画面、訪問者エリアなど) は、セッションが閉じられている別の ASP アプリケーションに移動できます。 ASP ページの上部にある次のディレクティブを使用して、ページごとにそのページの Session オブジェクトが不要であることを ASP に通知できます。

<% @EnableSessionState=False %>

これを使用する十分な理由ディレクティブは、これらのセッションにはフレームセットに関する興味深い問題があるということです。 ASP は、セッション内で常に 1 つのリクエストだけが実行されることを保証します。これにより、ブラウザーがユーザーに対して複数のページを要求した場合、一度に 1 つの ASP 要求だけがセッションにアクセスするため、Session オブジェクトにアクセスするときに発生するマルチスレッドの問題が回避されます。残念ながら、フレームセット内のすべてのページは同時にではなく、順番に表示されます。すべてのフレームを表示するには、ユーザーは長時間待たなければならない場合があります。この話の教訓: 一部のフレームセット ページがセッションに依存しない場合は、@EnableSessionState=False ディレクティブを使用して ASP に必ず通知してください。

Session オブジェクトの使用に代わるセッション状態を管理する方法は数多くあります。少量の状態 (4 KB 未満) の場合は、通常、Cookie、QueryString 変数、および暗黙的変数を使用することをお勧めします。ショッピング カートなどのデータ量が大きい場合は、バックエンド データベースが最適です。 Web サーバー ファームの状態管理技術については多くのことが書かれています。詳細については、「セッション ステータスのリファレンス」を参照してください。

ヒント 7: コードを COM オブジェクトにカプセル化する

VBScript または JScript を大量に使用している場合は、コードをコンパイル済みの COM オブジェクトに移動することでパフォーマンスを向上できることがよくあります。コンパイルされたコードは通常、解釈されたコードよりも高速に実行されます。コンパイルされた COM オブジェクトは、スクリプトで使用される「遅延バインディング」よりも効率的な COM オブジェクトの呼び出し方法である「早期バインディング」を通じて他の COM オブジェクトにアクセスできます。

コードを COM オブジェクトにカプセル化すると、(パフォーマンス以外にも) いくつかの利点があります。

COM オブジェクトは、プレゼンテーション ロジックをビジネス ロジックから分離するのに役立ちます。
COM オブジェクトにより、コードの再利用が保証されます。
多くの開発者は、VB、C++、または Visual J++ で書かれたコードの方が ASP よりもデバッグが簡単であると感じています。
COM オブジェクトには、初期開発に時間がかかり、さまざまなプログラミング スキルが必要になるなどの欠点もあります。少量の ASP をカプセル化すると、パフォーマンスが向上せずにパフォーマンスが低下する可能性があることに注意してください。この状況は通常、少量の ASP コードが COM オブジェクトにカプセル化されている場合に発生します。この場合、COM オブジェクトの作成と呼び出しのオーバーヘッドが、コンパイルされたコードの利点を上回ります。 ASP スクリプトと COM オブジェクト コードのどの組み合わせが最高のパフォーマンスを生み出すかを判断するには、試行錯誤を使用する必要があります。 Windows 2000/IIS 5.0 では、Microsoft Windows NT® 4.0/IIS 4.0 と比較して、スクリプトと ADO のパフォーマンスが大幅に向上していることに注意してください。したがって、IIS 5.0 の導入により、コンパイルされたコードの ASP コードに対するパフォーマンス上の利点は減少しました。

ASP で COM を使用する利点と欠点の詳細については、「ASP コンポーネントのガイドライン」および「Microsoft Visual Basic 6.0 を使用した分散アプリケーションのプログラミング」を参照してください。 COM コンポーネントを展開する場合は、負荷をかけた状態でテストすることが特に重要です。実際、すべての ASP アプリケーションは当然のことながら負荷テストを行う必要があります。

ヒント 8: リソースは後で取得し、早めに解放する

参考までに、ちょっとしたヒントを紹介します。一般に、リソースは後で取得し、早めに解放する方が良いでしょう。これは、COM オブジェクトだけでなく、ファイル ハンドルやその他のリソースにも適用されます。

この最適化方法は主に ADO 接続とレコードセットに使用されます。レコードセットの使用が完了したら、たとえばテーブルとそのデータを表示した後、ページの終わりまで待つのではなく、すぐにレコードセットを解放する必要があります。 VBScript 変数を Nothing に設定することをお勧めします。レコードセットを範囲外にしないでください。また、関連する Command オブジェクトまたは Connection オブジェクトをすべて解放します (レコードセットまたは接続を = Nothing に設定する前に、Close() を呼び出すことを忘れないでください)。これにより、データベースがリソースを準備する時間が短縮され、データベース接続が接続プールにできるだけ早く解放されます。

ヒント 9: アウトプロセス実行ではパフォーマンスと信頼性をトレードオフにする

ASP と MTS/COM+ の両方に、信頼性とパフォーマンスをトレードオフできる構成オプションがあります。アプリケーションを構築およびデプロイするときは、両方のパフォーマンスのバランスをとる方法を知っておく必要があります。

ASP オプションは、ASP アプリケーションが 3 つの方法のいずれかで実行されるように構成します。 IIS 5.0 では、これらのオプションを説明するために「分離レベル」という用語が導入されました。 3 つの分離レベルは、低レベル、中レベル、および高レベルです:

低レベル分離。これは IIS のすべてのバージョンでサポートされており、最も高速です。これは、IIS のメイン プロセスである Inetinfo.exe で ASP を実行します。 ASP アプリケーションがクラッシュすると、IIS もクラッシュします。 (IIS 4.0 で IIS を再起動するには、Web サイト管理者が InetMon などのツールを使用してサイトを監視し、サーバーに障害が発生した場合にサーバーを再起動するバッチ ファイルを有効にする必要があります。IIS 5.0 では、障害が発生したサーバーを自動的に再起動する方法である信頼性の高い再起動が導入されました。 ）。
中間分離。 IIS 5.0 では、この新しいレベルが導入されました。ASP は IIS プロセスの外で実行されるため、アウトオブプロセス レベルと呼ばれます。中間分離では、中間分離として実行するように構成されたすべての ASP アプリケーションがプロセス領域を共有します。これにより、単一サーバー上で複数のアウトプロセス ASP アプリケーションを実行するために必要なプロセスの数が削減されます。中分離は、IIS 5.0 のデフォルトの分離レベルです。
高度な分離。このレベルは IIS 4.0 および IIS 5.0 でサポートされており、高度な分離もプロセス外で行われます。 ASP がクラッシュしても、Web サーバーはクラッシュしません。 ASP アプリケーションは、次回 ASP 要求が行われたときに自動的に再起動します。高度な分離では、高度な分離として実行するように構成された各 ASP アプリケーションは、独自のプロセス空間で実行されます。これにより、ASP アプリケーションが相互に干渉するのを防ぎます。欠点は、ASP アプリケーションごとに個別のプロセスが必要なことです。多くのアプリケーションを 1 台のサーバーで実行する必要がある場合、システムのオーバーヘッドが大幅に増加します。
どのオプションが最適ですか? IIS 4.0 では、プロセスが不足するとパフォーマンスが大幅に低下します。 IIS 5.0 では、ASP アプリケーションをプロセス外で実行することによって生じるオーバーヘッドを最小限に抑えるために、多くの改善が加えられています。実際、ほとんどのテストでは、IIS 5.0 の ASP アウトプロセス アプリケーションは、IIS 4.0 のインプロセス アプリケーションよりも高速に実行されました。いずれにせよ、どちらのプラットフォームでも、インプロセス (分離レベルが低い) が最高のパフォーマンスを発揮します。ただし、アクセス速度が比較的低い場合、または最大スループットが低い場合、低い分離レベルの利点はあまり明らかではありません。したがって、低い分離レベルの設定が必要になるのは、Web サーバーごとに 1 秒あたり数百または数千のページが必要な場合のみです。いつものように、複数の構成をテストして、どの妥協点を設けるべきかを決定します。

ASP アウトプロセス アプリケーション (分離性が中または高) を実行する場合、アプリケーションは NT4 では MTS で、Windows 2000 では COM+ で実行されることに注意してください。つまり、NT4 では Mtx.exe で実行され、Windows 2000 では DllHost.exe で実行されます。これらのプロセスがタスク マネージャーで実行されているのを確認できます。 IIS がアウトプロセス ASP アプリケーション用に MTS パッケージまたは COM+ アプリケーションを構成する方法も確認できます。

COM オプション COM コンポーネントにも 3 つの構成オプションがありますが、ASP オプションとまったく同じではありません。 COM コンポーネントは、「未構成」にすることも、ライブラリ アプリケーションとして構成することも、サーバー アプリケーションとして構成することもできます。 「未構成」は、コンポーネントが COM+ に登録されていないことを意味します。コンポーネントは呼び出し側プログラムのプロセス空間で実行されます。つまり、コンポーネントは「インプロセス」になります。ライブラリ アプリケーションもインプロセスですが、セキュリティ、トランザクション、コンテキスト サポートなどの COM+ サービスを使用します。サーバー アプリケーションは、独自のプロセス空間内で実行されるように構成されています。

未構成のコンポーネントには、ライブラリ アプリケーションよりも若干の利点があることがわかります。ライブラリ アプリケーションには、サーバー アプリケーションよりもパフォーマンス上の利点があります。これは、ライブラリ アプリケーションが ASP と同じプロセスで実行されるのに対し、サーバー アプリケーションは独自のプロセスで実行されるためです。プロセス間呼び出しは、プロセス内呼び出しよりもコストが高くなります。さらに、レコードセットなどのデータをプロセス間で受け渡す場合、すべてのデータを 2 つのプロセス間でコピーする必要があります。

トラップ！ COM サーバー アプリケーションを使用する場合、ASP と COM の間でオブジェクトを受け渡す場合は、オブジェクトが「値によるバンドル」または MBV を実行することを確認してください。 MBV を実行するオブジェクトは、あるプロセスから別のプロセスに自身をコピーします。これは、オブジェクトがまだ作成者のプロセス内にあり、別のプロセスがオブジェクトを使用するために作成プロセスを繰り返し呼び出すアプローチよりも優れています。切断された ADO レコードセットは「値によってクラスター化」されますが、接続されたレコードセットはクラスター化されません。 Scripting.Dictionary は MBV を実行せず、プロセス間で渡されません。最後に、VB プログラマへの注意事項: MBV はパラメータ ByVal を渡すことによって取得されるわけではありません。 MBV は、元のコンポーネントの作成者によって実行されます。

何をするか？
パフォーマンスと信頼性のバランスをとる適切な構成を提案するように求められたら、次のようになります。IIS

4.0 では、ASP の低分離レベルを使用し、MTS サーバー パッケージを使用します。
IIS 5.0 では、ASP の中分離レベルを使用し、COM+ ライブラリ アプリケーションを使用します。
これらは非常に一般的な原則であり、ホスティング会社は通常、ASP を中程度または高い分離レベルで実行しますが、単一目的の Web サーバーは低い分離レベルで実行できます。長所と短所を比較検討し、どの構成がニーズに適しているかを自分で決定してください。

ヒント10：露示オプションの使用

オプションexplicitは.aspファイルで使用する必要があります。この指令は.aspファイルの上部に配置され、開発者に使用されるすべての変数を宣言するように強制します。多くのプログラマーは、変数名を間違え、誤って新しい変数を作成する可能性を回避するため、アプリケーションのデバッグに役立つと感じています（たとえば、myxmlstring =）の代わりに= ..

おそらくもっと重要なことは、宣言された変数は、未宣言の変数よりも高速であることです。このように、スクリプトが実行時に未表変数を使用するたびに、名前で参照します。一方、コンパイル時間または実行時間のいずれかで、変数は順番に宣言されます。これからは、宣言された変数がこの順序で参照されます。オプション明示的な強制変数宣言であるため、すべての変数が宣言されることを保証するため、アクセスは高速です。

ヒント11：サブルーチンおよび関数でローカル変数を使用して、

ローカル変数は、サブルーチンと関数内で宣言された変数です。関数またはサブルーチン内では、ローカル変数アクセスはグローバル変数アクセスよりも高速です。ローカル変数を使用すると、コードがより明確になるため、可能な限りローカル変数を使用する必要があります。

ヒント12：頻繁に使用されるデータをスクリプト変数にコピーして、

ASPでcomオブジェクトにアクセスするときに、頻繁に使用されるオブジェクトデータをスクリプト変数にコピーする必要があります。これを行うと、COMメソッド呼び出しが減少します。これは、スクリプト変数にアクセスするのと比較して比較的高価です。また、この手法は、コレクションおよび辞書オブジェクトにアクセスするときに高価な検索を減らします。

一般に、オブジェクトデータに複数回アクセスする予定がある場合は、データをスクリプト変数に配置する必要があります。この最適化の主なターゲットは、リクエスト変数（フォームとクエリの変数）です。たとえば、サイトはuseridという名前のクエリストリング変数を渡すことができます。このユーザーIDが特定のページで12回参照されるとしましょう。リクエスト（？userid？）を12回呼び出す代わりに、aspページの上部にある変数にuseridを割り当てることができます。次に、ページ全体でその変数を使用します。これにより、11のCOMメソッド呼び出しが節約されます。

実際、COMプロパティやメソッドへのアクセスはそれほど高価ではありません。これは、かなり一般的なコード（構文的に言えば）の例です：

foo.bar.blah.baz = foo.bar.blah.qaz（1）
foo.bar.blah.zaq = foo.bar.blah.abc then '...
このコードが実行されると、何が起こるかがあります。

変数fooはグローバルオブジェクトに解決されます。
変数バーは、FOOのメンバーとして解決されます。これは実際にはCOMメソッド呼び出しです。
可変BLAHは、foo.barのメンバーとして解決されます。これは別のCOMメソッド呼び出しです。
変数QAZは、foo.bar.blahのメンバーとして解決されます。そうです、これはまだCOMメソッド呼び出しです。
foo.bar.blah.quaz（1）に電話してください。別のcomメソッド呼び出し。わかった？
バズを解析するために、手順1〜3を再度実行します。システムは、QAZを呼び出すことがオブジェクトモデルを変更するかどうかを知らないため、BAZを解決するためにステップ1〜3を再度実行する必要があります。
foo.bar.blahのメンバーとしてBazを解決します。属性を割り当てます。
ZAQを解析するために、手順1〜3をもう一度実行します。
ABCを解析するために、手順1〜3を再度実行します。
ご覧のとおり、効率は非常に貧弱です（そして遅い）。このコードをvbscriptに記述するための簡単な方法は次のとおりです。Myobj

= foo.bar.blah '' blahの解像度を1回実行します
myobj.baz = myobj.qaz（1）
myobj.zaq = myobj.abc then '...
VBScript 5.0以上を使用している場合は、with statement：

with foo.bar.blah

.baz = .qaz（1）
if .zaq = .abc then '...
...

この手法はVBプログラミングにも適用されることに注意し

てください

可能であれば、

再次元の配列リダイムアレイ

パフォーマンスに関しては、コンピューターの物理メモリサイズが制限されている場合、配列の初期ディメンションを最悪のシナリオに設定するか、次元を最良のシナリオに設定し、次に再次元を設定することをお勧めします。必要に応じて。これは、あなたがそれを必要としないことを知っているときに、数匹のメガバイトのメモリを割り当てることを意味するものではありません。

次のコードには、DIMとRedimの不適切な使用が示されています。

<%
dimmyArray（）
RedimmyArray（2）
MyArray（0）=？こんにちは？
myArray（1）=？さようなら？
MyArray（2）=？Forewell？
...
'より多くのスペースが必要になる他のコードが発生します。
MyArrayをRedim Preserve（5）
myArray（3）=？もっともの？
MyArray（4）=？さらに多くのもの？
MyArray（5）=？まだもっと多くのもの？
％>

アレイの初期サイズ（この場合は5）からアレイの初期サイズを正しく暗くする方が、アレイをリダイムして大きくする方がはるかに優れています。メモリを無駄にすることができます（すべての要素を使用しない場合）が、利点はより速くなることです。

ヒント14：応答バッファリングの使用

「応答バッファリング」を有効にすることで、出力のページ全体をバッファすることができます。これにより、ブラウザへの書き込みの量が最小限に抑えられ、全体的なパフォーマンスが向上します。各書き込み操作には、重大なオーバーヘッドが発生します（IISとネットワーク上で送信されるデータの量の両方で）、より良い書き込みの方が少ないほどです。起動が遅く、ナグリングアルゴリズムの使用（ネットワークの輻輳を軽減するために使用）のため、TCP/IPは、多くの小さなチャンクを送信する必要がある場合よりも、いくつかの大きなデータを送信するときにはるかに効率的です。

応答バッファリングを有効にするには、2つの方法があります。まず、インターネットサービスマネージャーを使用して、アプリケーション全体の応答バッファリングを有効にすることができます。このアプローチをお勧めします。これは、IIS 4.0およびIIS 5.0の新しいASPアプリケーションのデフォルトで応答バッファリングを可能にします。次に、各ASPページの上部近くに次のコード行を追加することで応答バッファリングを有効にできます。

<％respons.buffer = true％>
このコード行は、応答データがブラウザに書き込まれる前に実行する必要があります（つまり、ASPスクリプトにHTMLが表示され、Cookiesがresponse.cookiesコレクションを使用してCookieが設定される前に）。一般に、アプリケーション全体の応答バッファリングを有効にすることをお勧めします。これにより、すべてのページの上部に上記のコード行を記述する必要はありません。

レスポンス.フラッシュ
応答バッファリングに関する一般的な不満は、ユーザーがASPページが応答が遅くなると認識していることです（全体的な応答時間が改善されていても）。長期にわたるページの場合、Response.buffer = falseを設定して、応答バッファリングを無効にすることができます。ただし、より良い戦略は、Response.flushメソッドを利用することです。この方法は、ASPによって変換されたすべてのHTMLをブラウザに送信します。たとえば、1,000列のテーブルの最初の100行を変換した後、ASPは応答を呼び出してブラウズの結果をブラウザに強制し、残りの行の準備が前に最初の100行を表示できるようにします。この手法は、応答バッファリングとブラウザのデータを徐々に表示することを完全に組み合わせています。

（上記の1,000列のテーブルの例では、多くのブラウザがクロージング</table>タグが表示されるまでテーブルの表示を開始しないことに注意してください。ターゲットブラウザーがサポートしているかどうかを確認してください。これを避けるために、テーブルを複数のテーブルに分割します。各テーブルの後、インターネットエクスプローラーが完全にダウンロードされる前に、レスポンスが少ない。各セルのコンテンツ幅。）

応答バッファリングに関する別の一般的な苦情は、非常に大きなページが生成されたときに多くのサーバーメモリを占めることです。大きなページを生成する方法に関係なく、この問題は、Response.flushの巧妙な使用によって解決することもできます。

ヒント15：バッチ埋め込みスクリプトと応答

。応答バッファリングが有効になっていない場合、実行された各ステートメントは、ネットワーク上の多くの小さなパケットでブラウザにデータを書き込みます。これは非常に遅いです。さらに、少量のスクリプトとHTMLの実行が散在すると、スクリプトエンジンとHTML間の切り替えによりパフォーマンスが低下します。したがって、次のトリックを使用します。緊密にバンドルされたインライン式の代わりに、respons.write呼び出しを使用します。たとえば、次の例では、行ごとのフィールドごとに応答ストリームに1つの書き込みがあり、行ごとのVBScriptとHTMLの間には多くのスイッチがあります

。
rs.Fields％の各FLDの<％>
<th> <％= fld.name％> </th>
<%
次
rs.eofではありませんが
%>
<tr>
rs.Fields％の各FLDの<％>
<td> <％= fld.value％> </td>
<％次へ
</tr>
<％rs.movenext
ウェン %>
</テーブル>
以下のコードはより効率的で、1行あたりの応答ストリームに書き込みが1つあります。すべてのコードは、vbscriptブロック内に含まれています：

<table>
<%
Rs.Fieldsの各FLDについて
respons.write（？<th>？＆fld.name＆？</th>？＆vbcrlf）
次
rs.eofではありませんが
respons.write（？<tr>？）
rs.Fields％>の各FLDについて
respons.write（？<td>？＆fld.value＆？</td>？＆vbcrlf）
次
respons.write？</tr>？
ウェン
%>
</テーブル>
このトリックは、応答バッファリングが無効になっている場合に特にうまく機能します。応答バッファリングを有効にし、バッチングResponse.Writeがパフォーマンスの向上に役立つかどうかを確認することをお勧めします。

（この特定の例では、テーブルの本体を構築するネストされたループ（rs.eof ...ではありませんが）は、慎重に構築されたGetStringコールに置き換えることができます。）

ヒント16：ページが完了するのに長い時間がかかる場合、 respons.isclientConnectedを使用する前にユーザーが焦りをしている場合は

、リクエストの実行を開始する前にASPページを放棄する場合があります。 [更新]をクリックするか、サーバー上の別のページに移動すると、ASPリクエストキューの最後に新しいリクエストが待機し、キューの途中で切断されたリクエストがあります。これは、サーバー上の負荷が高いときにしばしば発生します（したがって、リクエストキューは長く、応答時間はそれに応じて長くなります）。これは状況を悪化させるだけです。ユーザーが接続されなくなった場合、ASPページ（特に遅い、大きなASPページ）を実行することには意味がありません。 respons.isclientConnectedプロパティを使用してこれを確認できます。 falseを返す場合、response.Endは呼び出され、ページの残りの部分を破棄する必要があります。実際、IIS 5.0にはこの動作がプログラムされています - ASPが新しいリクエストを実行しようとするたびに、リクエストがキューで待っている期間をチェックします。 3秒以上待っていた場合、ASPはクライアントがまだ接続されているかどうかを確認します。そうでない場合は、すぐにリクエストを終了します。メタベースのAspqueueConnectionTestipe設定を使用して、3秒から別の値にタイムアウトを調整できます。

また、ページが完了するのに長い時間がかかる場合、respons.isclientConnectを時々確認することもできます。応答バッファリングが有効になっている場合、応答を実行することをお勧めします。時々、ユーザーに何が起こっているのかを知らせます。

IIS 4.0では、response.writeが最初に実行されない限り、response.isclientConnectedは正しく機能しないことに注意してください。バッファリングが有効になっている場合は、Response.Flushも実行する必要があります。 IIS 5.0では、これを行う必要はありません-Response.IsclientConnectedは正常に動作します。いずれにせよ、response.isclientConnectedにはオーバーヘッドがあるため、操作に少なくとも500ミリ秒（たとえば）が必要な場合のみ（1秒あたり数十ページのスループットを維持する場合は長い時間）使用します。エクスペリエンスによると、テーブルの多くの行を表示するときなど、20行または50行ごとに呼び出すときなど、タイトループが繰り返し実行されるたびに電話をかけないでください。

ヒント17：

すべてのコードパス（特にサーバーまたはアプリケーションスコープオブジェクト）で使用されていないオブジェクトを参照する場合は、インスタンス化されたオブジェクトに<オブジェクト>タグを使用し、<オブジェクトrunat = server id = objname>タグを使用しますserver.createObjectメソッドを使用する代わりに、global.asaの宣言。 server.createObjectすぐにオブジェクトを作成します。将来オブジェクトを使用しない場合、リソースを無駄にしました。 <object id = objname>タグはobjnameを宣言しますが、objnameはその方法またはプロパティが初めて使用されるまで作成されません。

これは怠zyな評価の別の例です。

ヒント18：ADOおよびその他のコンポーネントにTypelib宣言を使用して

ADOを使用する場合、開発者はさまざまなADO定数にアクセスするためにAdovbs.txtを追加します。このファイルは、定数を使用するすべてのページに含める必要があります。この一定のファイルは非常に大きく、各ASPページのコンピレーション時間とスクリプトサイズに多くのオーバーヘッドを追加します。

IIS 5.0は、コンポーネントタイプライブラリにバインドする機能を導入しました。これにより、タイプライブラリを1回参照し、すべてのASPページで使用できます。各ページの定数ファイルをコンパイルするオーバーヘッドはありません。コンポーネント開発者は、ASPで使用するためにVBScript＃_Includeファイルを作成する必要はありません。

ADO Typelibにアクセスするには、以下のステートメントをGlobal.ASAに配置します。

<！ - メタデータ名=？Microsoft ActiveXデータオブジェクト2.5ライブラリ？
type =？typelib？
または

<！ - メタデータタイプ=？Typelib？

program

files common files ado msado15.dll

？サービスはサポートを提供します。可能な限りこれらの機能を使用してください。これらのテクノロジーはすべて、クライアント側の検証とデータキャッシュを実行し、Webサーバーへの往復の必要性を排除します。スマートブラウザを実行している場合、ブラウザはあなたのために何らかの検証を行うことができます（たとえば、投稿を実行する前にクレジットカードチェックサムが有効であることを確認します）。可能な限りこの機能を使用してください。クライアントサーバーのラウンドトリップを削減することにより、Webサーバーの負荷を削減し、ネットワークトラフィック（ブラウザに送信された最初のページが大きくなる場合があります）とサーバーがアクセスするバックエンドリソースを削減します。さらに、ユーザーはいつものように新しいページを読む必要がないため、ユーザーの気分が良くなります。これを行うことは、サーバー側の検証をスキップできるという意味ではありません。常にサーバー側の検証を行う必要があります。これにより、クライアントが何らかの理由で誤ったデータを生成することを防ぎます（ハッカーや、クライアント側の検証ルーチンを実行していないブラウザなど）。

「ブラウザに依存しない」HTMLの開発には、多くの作業が行われています。この懸念のため、開発者はパフォーマンスを改善できる一般的なブラウザ機能を使用することに消極的です。いくつかの真に高性能サイトの場合、ブラウザの「アクセス」の問題が関係する必要があり、適切な戦略はページを最適化して人気のあるブラウザに適応することです。ブラウザ機能は、ブラウザ機能コンポーネントを使用してASPで簡単に検出できます。 Microsoft FrontPageなどのツールは、HTMLのブラウザや特定のバージョンに適した設計コードをヘルプします。いつもっと悪いのかわかりますか？さらなる議論のためにテクノロジーのトレードオフを比較検討します。

ヒント20：ループで文字列連結を使用しない

で

ください
Rs.Fieldsの各FLDについて
s = s＆？＆fld. </th>？
次に、

rs.eofではありません
s = s＆vbcrlf＆？
Rs.Fieldsの各FLDについて
s = s＆？＆fld.value＆？</td>
次
s = s＆？
rs.次へ移動
wend

s = s＆vbcrlf＆？</table>？
Response.Write s
このアプローチでいくつかの問題が発生します。最初の問題は、繰り返し連結すると、2つのパワーに時間がかかることです。このようなループを実行するのにかかる時間は、フィールドの数を掛けたレコード数に比例します。より単純な例では、この問題をより明確に説明します。

s = ??
i = asc（？a？）to asc（？z？）の場合
s = s＆chr（i）
次
最初の反復では、1文字の文字列を取得しますか？A？ 2番目の反復では、VBScriptは文字列を再配置し、2文字（？ab？）をsにコピーする必要があります。 3回目の反復では、再びsを再割り当てし、3文字をsにコピーする必要があります。 n（26）の反復では、n文字を再割り当てしてsにコピーする必要があります。合計は1+2+3+...+n、つまりn*（n+1）/2コピーです。

上記のレコードセットの例では、100のレコードと5つのフィールドがある場合、内側ループが100*5 = 500回実行され、すべてのコピーと再割り当てに費やされる時間は500*500 = 250,000に比例します。これは、中程度のサイズのレコードセットではコピー操作が多すぎます。

この場合、文字列連結の代わりにrespons.write（）またはinlineスクリプト（<％= fld.value％>）を使用することにより、コードを改善できます。応答バッファリングが有効になっている場合（必要な）、応答が速度であるため、これはより高速になります。リアルロケーションは含まれていないため、非常に効率的です。

ADOレコードセットをHTMLテーブルに変換する特定のケースでは、GetRowsまたはGetStringの使用を検討する必要があります。

jscriptで文字列を連結している場合、 += operatorを使用することを特にお勧めします。つまり、s = s +？a string？

ヒント21：ブラウザとプロキシキャッシュを

デフォルトで有効にして、ASPはブラウザーとプロキシでキャッシュを無効にします。 ASPページは本質的に動的であり、時間の経過とともに変化する根本的な情報があるため、これは理にかなっています。ページがすべてのビューで更新を必要としない場合は、ブラウザとプロキシキャッシングを有効にする必要があります。これにより、ブラウザとプロキシは、ページの「キャッシュされた」コピーを一定の時間使用できますが、その長さを制御できます。キャッシュは、サーバーの負荷を大幅に削減し、ユーザーの待ち時間を短縮することができます。

キャッシュされるページとして使用できる動的ページはどれですか？いくつかの例を次に示します。

天気予報ページ、このページでは、5分ごとに天気予報が更新されます。
ホームページリストニュース項目またはリリース、1日2回更新されます。
数時間ごとに基本統計が更新されるミューチュアルファンドのパフォーマンスのリスト。
ブラウザまたはプロキシキャッシングを使用すると、Webサーバーに記録されている訪問数が減少することに注意してください。すべてのページビューまたは投稿を正確に測定する場合は、ブラウザとプロキシキャッシングを使用する必要はありません。

ブラウザキャッシュは、Webサーバーによってブラウザに送信されるHTTP「有効期限」ヘッダーによって制御されます。 ASPは、このヘッダーを送信するための2つの簡単なメカニズムを提供します。ページが期限切れになる数分数を設定するには、Response.Expiresプロパティを設定します。

、

コンテンツが10分で期限切れになることをブラウザに示します

。サーバーとブラウザの時計の間の不一致を避けるために、-1000（1日以上）などの大きな負の数を使用してください。

では

、コンテンツの有効期限が切れる特定の時間を設定できます。

応答オブジェクトを使用して有効期限を設定する代わりに、<meta>タグをHTML（通常はHTMLファイルの<head>セクション）に書き込むことができます。一部のブラウザはこの指令を尊重しますが、プロキシは尊重しません。

<メタhttp-equiv =？value =？5月31,2001 13:30:15？>
最後に、Response.CacheControlプロパティを使用して、そのコンテンツをHTTPプロキシによってキャッシュできるかどうかを示すことができます。このプロパティを「パブリック」に設定すると、プロキシがこのコンテンツをキャッシュできます。

<％response.cachecontrol =？public>
デフォルトでは、このプロパティは「プライベート」に設定されています。プロキシは他のユーザーに属するユーザーページにサービスを提供する可能性があるため、ユーザーに固有のデータを表示するページに対してプロキシキャッシュを有効にしないでください。

ヒント22：response.redirectの代わりにserver.transferを使用してください

。この関数は、一般に、ユーザーをログインまたはエラーページにリダイレクトするために使用されます。リダイレクトは新しいページのリクエストを強制するため、その結果、ブラウザはWebサーバーに2回のラウンドトリップを行う必要があり、Webサーバーは1つのリクエストを処理する必要があります。 IIS 5.0は、新しいfunction server.transferを導入します。これは、同じサーバー上の別のASPページに実行を転送します。これにより、冗長なブラウザ-WEBサーバーのラウンドトリップが回避され、システム全体のパフォーマンスとユーザーの応答時間が改善されます。 「リダイレクト」の「新しい方向」を確認すると、server.transferとserver.executeである必要があります。

IIS 5.0およびASP 3.0の新機能の完全なリストについては、IIS 5.0のレバレッジASPも参照してください。

ヒント23：ディレクトリでバックスラッシュを使用するURLS

関連するヒントは、ディレクトリを指すURLでバックスラッシュ（/）を使用することです。トレーリングスラッシュを省略した場合、ブラウザはサーバーにディレクトリを要求していることを指示するためだけにサーバーにリクエストを行います。ブラウザは2番目の要求を行い、URLにスラッシュを追加し、その場合にのみ、ディレクトリのデフォルトドキュメントまたはディレクトリリストでサーバーが応答できます（デフォルトのドキュメントがなく、ディレクトリブラウジングが有効になっている場合）。スラッシュを追加すると、最初の、役に立たないリターンがなくなります。ユーザーが読みやすくするために、ディスプレイ名のトレーリングスラッシュを省略できます。

たとえば、書き込み：

<a href =？http：//msdn.microsoft.com/workshop/？title =？msdn web
ワークショップ？> http://msdn.microsoft.com/workshop </a>
これは、Webサイトのホームページを指すURLにも適用されます。次のことを使用してください。<a href =？http：//msdn.microsoft.com/？> 。

ヒント24：サーバー変数にアクセスすると、

Webサイトがサーバーに特別なリクエストを行い、要求したサーバー変数だけでなく、すべてのサーバー変数を収集します。状況は、かび臭い屋根裏部屋のフォルダー内のファイルを検索することに似ています。そのドキュメントを見つけたいときは、屋根裏部屋に行き、フォルダーを見つけて、ドキュメントを見つける必要があります。サーバー変数を要求すると同じことが起こります。サーバー変数を初めてリクエストするとき、パフォーマンスは低下します。他のサーバー変数への後続の要求は、パフォーマンスに影響を与えません。

資格のない要求オブジェクトにアクセスしないでください（たとえば、要求（ "データ"））。 request.servervariablesは、request.cookies、request.form、request.querystring、またはrequest.clientCertificateにないアイテムに対して暗黙的に呼ばれます。 Request.Servervariablesコレクションは、他のコレクションよりもはるかに遅いです。

ヒント25：最新の最大の

システムコンポーネントへのアップグレードは一定であり、最新かつ最大の構成にアップグレードすることをお勧めします。 Windows 2000にアップグレードするのが最善です（したがって、IIS 5.0、ADO 2.5、MSXML 2.5、Internet Explorer 5.0、VBScript 5.1、およびJScript 5.1）。マルチプロセッサコンピューターでは、IIS 5.0とADO 2.5を実装すると、パフォーマンスを大幅に改善できます。 Windows 2000では、ASPは4つのプロセッサ以上を十分にスケーリングしますが、IIS 4.0では、ASPは2つのプロセッサを超えてスケ​​ーリングしません。アプリケーションで使用するスクリプトコードとADOが多いほど、Windows 2000にアップグレードした後、パフォーマンスの改善が増えます。

Windows 2000にまだアップグレードできない場合は、SQL Server、ADO、VBScript、JScript、MSXML、Internet Explorer、およびNT 4サービスパックの最新バージョンにアップグレードできます。どちらもパフォーマンスと信頼性を向上させます。

ヒント26：Webサーバーの最適化

サイトのパフォーマンスを改善できるさまざまなIIS最適化パラメーターがあります。たとえば、IIS 4.0では、ASP ProcessOrthReadMaxパラメーター（IISドキュメントを参照）を増やすと、特にバックエンドリソース（データベースなど）または他の中間製品を待つ傾向があるサイトでパフォーマンスを大幅に改善できることがよくあります。スクリーンブラシとして）。 IIS 5.0では、ASPスレッドゲーティングを有効にすることは、AspprocessorThreadMaxの最適な設定を見つけるよりも効率的であることがわかります。

参照については、以下のIISの最適化を参照してください。

最適な構成設定は、他の要因の中でも、実行中のシステムハードウェア、およびクライアントワークロードに依存します。最適な設定を見つける唯一の方法は、パフォーマンステストを実行することです。これについては、次のヒントで説明します。

ヒント27：パフォーマンステストを実施したこと

は、以前に言ったように、パフォーマンスは特徴です。サイトのパフォーマンスを改善したい場合は、パフォーマンスの目標を設定し、到達するまで徐々に改善します。いいえ、パフォーマンステストは実行されません。多くの場合、プロジェクトの終わりまでに、必要な構造変更を行うには遅すぎます。クライアントは失望します。テストルーチンの一部としてパフォーマンステストを実施します。 ASPページやCOMオブジェクトなど、個々のコンポーネントで個別にパフォーマンステストを実行できます。

多くの人が単一のブラウザを使用してページをリクエストして、Webサイトのパフォーマンスをテストします。これを行うと、サイトは応答性が高いという感覚が得られますが、実際には、サイトがどのように負荷の下で機能するかはわかりません。

通常、パフォーマンスを正確にテストするには、専用のテスト環境が必要です。この環境には、プロセッサの速度、プロセッサの数、メモリ、ディスク、ネットワーク構成など、生産環境に似たハードウェアが含まれている必要があります。第二に、クライアントのワークロードを指定する必要があります。同時ユーザーの数、リクエストを行う頻度、クリックするページの種類などを指定する必要があります。実際のサイトの使用に関するデータがない場合は、使用法を推定する必要があります。最後に、予想されるクライアントワークロードをシミュレートできるツールが必要です。これらのツールを使用すると、「n同時ユーザーがいる場合、必要なサーバーの数」などの質問に答え始めることができます。また、ボトルネックの原因を特定し、それらに対して最適化することもできます。

以下にリストされているのは、いくつかの優れたWebロードテストツールです。特に、Microsoft Webアプリケーションストレス（WES）ツールキットをお勧めします。テストスクリプトを記録し、Webサーバーにアクセスする数百または数千人のユーザーをシミュレートできるようにしました。 1秒あたりの要求、応答時間分布、エラーカウントなど、多くの統計が報告されていました。リモートテストを実施できるリッチなクライアントインターフェイスとWebベースのインターフェイスの両方で利用できます。

IIS 5.0チューニングガイドを必ずお読みください。

ヒント28：以下のリソースリンクを読むことは

、いくつかの優れたパフォーマンス関連のリソースへのリンクです。それについて学びたい場合は、スケーラブルなWebアプリケーションの開発をお読みください。

リソース最適化Scalable Webアプリケーションの開発は、

Nancy

Winnick

によるアクティブサーバーページのパフォーマンスを最大化

し

ます

ナンシーウィニッククラッツによる

速度と最適化リソース

IISの最適化

Webサーバーのアートと科学インターネット情報サービス5.0

IIS 5.0でのレバレッジASP、

JD Meierの大量サイトのIIS 4.0のチューニング、チューニングインターネット情報のチューニングMichael Stephensonによるサーバーパフォーマンス

Mike Mooreによる

Webサーバーパフォーマンス最適化の設定の迷路のナビゲート

Todd Wanke、

Ado、SQL Server

トップ10のヒント：ADOとASPを介したSQLのアクセス

改善

JD Meier

によるMDACアプリケーションのパフォーマンス

Suresh Kannan、SQL ServerによるMicrosoft Data Accessコンポーネントのプーリング、

SQL Server：Leland AhlbeckおよびDon Willitsによるパフォーマンスベンチマークとガイドは

、IIS 4.0、

Microsoft Data Accessコンポーネント（ MDAC）およびActiveX Data Objects（ADO）パフォーマンスのヒントLeland Ahlbeck、

Microsoft

SQL Server 7.0実用的なパフォーマンスの調整と最適化 - Leland Ahlbeck、Microsoft SQL Server 7.0のサーバーの視点は

、Damien Lindauerによるサーバーの視点 - Damien Lindauerによるアプリケーションの視点

JD Meier

によるDino Esposito

ASP

：

Nancy Winnick Clutsが

一緒に

し

Nancy Winnick Cluts

によるATLを使用したアクティブサーバーコンポーネント

Neil Allain

によるC ++による高性能ミドル層コンポーネント

アクティブサーバーページ、Com、Jon Flanders Apartments、Don Box、

House of Com： Active Serverページ、Don Box、

House of Com：Contexts、Don Box、

House of Com：Windows 2000コンポーネント実行環境のパフォーマンストレードオフ、Don Box、

視覚的な基本とスクリプトを最大限に活用するCOMコンポーネントの構築、Ivo Salmreコンポーネントによる

辞書コンポーネント

の

デザイン原理

ページキャッシュオブジェクトの作成、Robert Coleridge by

Robert

Coleridge

dictionaryオブジェクト：ASPチームはルックアップテーブルオブジェクトを作成します。

Q175167：howto：セッションなしでの持続値

Q157906

：howto：vbscript xmlベースの持続性行動でページ全体で状態を維持する方法

of

COM

によるWebファームヘッジ

Microsoft Windows DNAプラットフォームサーバーのパフォーマンスとスケーラビリティキラーを使用したサイト

、

George Reilly

Microsoft Visual Studio Scalability Center

Fitch

＆

Mather

ストック2000

Buildingが静的HTMLから高性能Webファームまでのそれらを防ぐ方法Shawn Bice

Microsoft

Web

アプリケーション

ストレス

ツール

Bibliography

によるVisual Studio Analyzerを使用した分散アプリケーションでの

パフォーマンスキット

イベントプロフェッショナルアクティブサーバーページ3.0、Wrox Press（特に第26章：ASPパフォーマンスの最適化、ジョージライリー、マシューギブスとのジョージライリー）。

Microsoft Internet Information Services 5.0リソースガイド（Windows 2000 Server Resource Kit）、Microsoft Press。

Microsoft Internet Inferation Serverリソースキット（IIS 4.0用）、Microsoft Press。

Microsoft PressのTed Pattisonによる、COMおよびMicrosoft Visual Basic 6.0を使用したプログラミング分散アプリケーション。

Don Box、Keith Brown、Tim Ewald、Chrisが販売する効果的なCom。

Webユーザビリティの開発：シンプルさの実践、Jakob Nielsen、新しいライダー。

Learnasp.com

4GUYSFROMROLLA.com

ASP Web SitesMicRosoft

Technet

15Sptoday.com

ASP101.com

ASPLISTS.com

。多くのプロのメーリングリストには、

次のものが含まれます。
ASP Advanced
Newbiestate Managementではありません
スケーラビリティ
視覚的な基本コンポーネント
XML
C ++/ATLコンポーネントビルディング
useit.com：webユーザビリティ

ASPスタイル

ASPベストプラクティスジョージライリー

ASP

チャールズキャロルによるクイックレッスン

ASP

ジョンミード

の

XML