ASP.NET Web Cache Spurs Performance and Scalability

[アーティクル]
08/25/2016

Web インフラストラクチャ

ASP.NET キャッシュ Spurs パフォーマンスとスケーラビリティ

Iqbal Khan

概要。

劇的なボトルネックの削減
静的および動的な Web キャッシュ
必要がありますが機能: 有効期限、PDF の部分的なコンテンツを依存関係をよりデータベース
グローバルの組織にとって特別な利点
Web キャッシュサーバークラスター
空きおよび商用ソリューション

問題: ASP.NET のボトルネック
ソリューション: ASP.NET のキャッシュ
Web キャッシュの機能をする必要があります。
有効期限の設定
有効期限の設定] ページの再読み込み
部分ページキャッシュ
データベースの依存関係
ファイルの依存関係
PDF の部分的なコンテンツ
ViewState のキャッシュ
Gzip 圧縮
スケーラブルで動的な Web キャッシュクラスター
地理的なキャッシュの配布
データベースの外からの維持します。
ガイドライン

ASP.NET、マイクロソフトの Web アプリケーションのフレームワーク、に基づいてアプリケーション、企業に大きい inroads を行っています。同時に、ユーザーとトランザクションの数の増加に起因するボトルネックは向上したパフォーマンスとスケーラビリティの呼び出しの IT プロフェッショナルの要求に進みます。

問題: ASP.NET のボトルネック

ボトルネックは、さまざまな理由の ASP.NET アプリケーションで発生します。最もわかりやすい: データストレージテクノロジは Web アプリケーションアーキテクチャとして、スケーラブルなないです。データ記憶域またはデータアクセスをすぐに扱う ASP.NET アプリケーション内の任意の場所では、アプリケーションを拡張しようとする場合に、logjam になります。 2 つの領域をこのような場所は、リレーショナルまたはメインフレームデータベースのセッション状態ストレージとアプリケーションのデータ ( 図 1 参照)。

図 1 を ASP.NET アプリケーションでパフォーマンスの共通部分のボトルネック

別のボトルネック場合、ASP.NET アプリケーションを行っているサービス - 指向アーキテクチャ (SOA) Web サービスへの呼び出しです。ここでは、Web サービスが、同じ問題として、ASP.NET アプリケーション (つまり、データストレージとアクセス)、遅延は起こりません。可能性は、Web サービスファームは、複数のアプリケーション間で共有されていると、つまり、スケーラビリティのボトルネックを作成よりずっと、1 つの ASP.NET アプリケーションの負荷中です。

ボトルネックは、ユーザーのブラウザーと ASP.NET の Web ファーム間でも行うことができます。これらの clogs は、集中的に使用する CPU の処理に関連する時に繰り返し実行する ASP.NET ページであるという事実に関連します。このプロセスはユーザーに大量のデータ要素 (画像やドキュメントなど) を繰り返し送信ではもされます。

以前に TechNet Magazine 記事では、説明した ASP.NET のパフォーマンスとスケーラビリティの問題、セッション状態およびアプリケーションデータ (を参照してください"に焦点 ASP.NET アプリケーションのスケーラビリティを提供します。、"2009年 6 月)。その記事で方法、問題が発生など、Web ファームが増えるにつれて、ASP.NET セッション状態が、logjam ことの理由が説明します。という事実を説明する分散型のインメモリキャッシュが、上位の代わりにマイクロソフトの既存の ASP.NET セッション状態のストレージオプション。アプリケーションのデータをデータベースからはスケーラビリティボトルネックの原因方法について説明しました。詳細方法分散キャッシュ解決それら ASP.NET セッション状態ストレージボトルネックの異なるキャッシュのトポロジ、さまざまな機能がすべてのアドレスのスケーラビリティを提供する各と 100% の稼働時間を保証すること。

最後に、する汎用プロファイル、さまざまなキャッシュ、市場で利用可能なオプションを配布します。いくつかのオプションより堅牢なや豊富な機能を使用した商用製品の中に他のユーザー制限機能を備えた自由できます。ただし、最適なパフォーマンスとスケーラビリティ] の上部の-行の市販製品を検討します。

ソリューション: ASP.NET のキャッシュ

背景として問題の定義をこの資料の主なはパフォーマンスおよびスケーラビリティのボトルネック、ユーザーのブラウザーと Web サーバーまたは Web ファームとの間です。理想的を Web ページ自体を実行する回数を減らしたいです。 Web ページが 1 回、実行、その出力がないも簡単に変更場合、しなぜ実行再度でしょうか。その理由は、出力をキャッシュだけでしょうか。次回ユーザーできますだけそのページの出力から直接フェッチそれを再実行ではなく、キャッシュします。 CPU が含まれます、メモリを消費し、その他の Web サーバーのリソースを使用して、ページを再実行など、もちろんはデータ記憶域からスケーラビリティのボトルネックの問題です。

Web サーバー自体に、ASP.NET ページの出力をキャッシュできる; Microsoft するためには、ASP.NET 出力キャッシュメカニズム示しもうまきます。ただし、私は 2 つの問題、ASP.NET 出力キャッシュに関する。

最初に、ASP.NET コードを追加、変更し、最低限、その出力をキャッシュすることを示すこれらのページにタグを配置する必要があります。必ずしも、IT 担当者が管理している内部で開発して、外部で ASP.NET アプリケーションを購入できます。また、アプリケーションコードを変更すると、いつでもことは、プロセスで何も違反していますを確認する品質保証の努力を通じて進む必要があります。これは、キャッシュを組み込むことのコストを増やします。

2 つ目は、ASP.NET 出力キャッシュはローカルの各 Web サーバーを実際には、各 ASP.NET ワーカープロセス内のページ出力キャッシュします。これにより、Web ガーデン (つまり、Web サーバー上の複数のワーカープロセス) や負荷分散された Web ファームがある場合の一貫性とスケーラビリティの面で大きな問題作成されます。このような場合は、キャッシュの複数の切断されたコピーを保持します。 Web サイトの高トラフィックを管理悪夢なるこの可能性があります。 ASP.NET 4. 0 で Microsoft がサードパーティ製の分散キャッシュを組み込むことにより、別のプロセスまたは層で、キャッシュを保持するためには拡張可能なキャッシュフレームワークを約束します。

この開発では、する Web サーバー] ではなくページ出力をキャッシュしたいがユーザーと Web 間に位置する独立した Web キャッシュサーバーでファーム (の種類、リバースプロキシのように、 図 2 を参照してください)。代わり多数のユーザーの要求しない Web ファームにようにし、間に、キャッシュから送信にしている、Web ファーム上の負荷を削減し、Web ファームのスケーラビリティが向上します。 Web ページの出力キャッシュから取得し、ユーザーに戻すが実際にその Web ページを実行するよりもかなり少ないリソース必要です。なぜなら、キャッシュは、高性能でスケーラブルなインメモリストレージ、パフォーマンスとスケーラビリティに関する問題をすべてのディスクストレージとは異なりです。

図 2 Web キャッシュサーバーが座ってユーザーと Web サーバー。

このコンテキストでは、方法 Web ページの出力をキャッシュするボトルネックを解決できスケーラビリティとパフォーマンスの大幅向上説明します。 Web キャッシュサーバーは、これらの目標を実現する重要、役割を果たすことができます。

Web キャッシュサーバーように Web ページのチェックをそれらのページの出力をキャッシュに既に存在かどうかを確認を HTTP 要求を受け取ります。含まれている場合は、Web キャッシュサーバーは、ユーザーに出力するを返します。ユーザーの要求もしないように Web サーバーにします。キャッシュからフェッチされている、ためには、返されるは非常に高速です。メモリ内にあるページが再実行するにはないため、大量の CPU の処理がも保存されます。

Web キャッシュサーバーは、バックエンド Web テクノロジプラットフォーム使用できます。すべてのトーキング HTML と JavaScript いる、限りは、Web アプリケーションを Java、.NET、PHP または他のいくつかの言語で開発されたかどうかをかまいません。ただし、Web キャッシュサーバー機能がソリューションからソリューションに異なるため、一部のプラットフォーム固有の機能を含めることができます。

2 種類の Web キャッシュソリューションがあります。主にかなりの静的データ、キャッシュされているすべてのページがいずれかと見なさことを意味をキャッシュ 1 完全に静的または予測可能な間隔を変更します。一定の時間、なた後、有効期限が切れる、キャッシュから削除されます、全体のページはキャッシュされます。他の種類は動的キャッシュ、つまりより動的な Web サイトまたは Web アプリケーションに適したです。

Web サイトまたは Web アプリケーションが動的、や頻繁に予期しないデータを変更する場合は動的キャッシュできるようにする必要があります。曜日は、ほとんどの Web サイト変更には、少なくともその内容をよくの一部。キャッシュものとしてで 15 ～ 30 秒間、ほとんどが通常の任意の場所数分から数時間にすることができます (数日週のいくつかの場合、します。

世界各地の大企業に重要な利点を提供する Web キャッシュ: Web キャッシュサーバーの地理的に配布する機能。ニューヨークでグローバルな組織で、メインの Web サイトのアプリケーションをホストすることがありますが、ユーザー、世界が、サンフランシスコのロンドンと東京とシドニーとドゥバイ。今すぐ簡単比較的に地理的にこれらの各領域にある Web キャッシュサーバーが存在します。ヨーロッパからのすべての要求、Web サイトをヒットする前に、ヨーロッパ言語の Web キャッシュサーバーが通過されます。そうする、大西洋を横断し、そのすべてのパケットが通る必要がある 100 ミリ秒遅延が発生する必要はありません。基本的に近くにあるキャッシュからそのコピーを入手することができます。

もう 1 つの例がみましょう。中東および南アジアの領域を提供しているドゥバイ内のサーバーがあり、何百も数千のユーザーが Web サイトを同時にヒットするを取得しました。 Web キャッシュ、ニューヨーク本社にメインデータセンターへのトラフィックが大幅に削除されます。すべてのトラフィックは時間で、すべてをキャッシュしないため、キャッシュするあらゆるもが無効に) する、キャッシュから削除されますが阻止されます。アプリケーションの性質に応じてするした可能性があります、トラフィックを 30 ～ 50% 削減します。

Web キャッシュの機能をする必要があります。

Web サイトは、時間の経過と共にのみが完全に対話型の Web アプリケーション動的データを頻繁に変更をするには静的コンテンツを表示から変換がします。そのつまり、今日では、Web キャッシュは、動的な Web サイトのすべての要件として扱う必要があります。目標はキャッシュにできるだけ多くの Web サイトのコンテンツ中に、できるだけ同時にキャッシュされたコンテンツは正しいとされていない古いまたは間の同期、データベース内の基になるデータを確実にです。すべてを処理するには、Web キャッシュには特定の機能のパフォーマンスとスケーラビリティを上げるときにデータの整合性の問題を回避する必要があります。

一般的な Web キャッシュソリューションには、次機能が含まれます。

有効期限の設定

有効期限機能を使用して長い方法については、キャッシュを Web ページに関する規則を指定できます。絶対またはスライド式のいずれかの時間にページの有効期限できます。絶対時刻しようとするものを特定の時間に期限切れの午前 0 時から 10 分後や今日現在かどうかは意味します。時間を変化するかどうかを特定のページが常にアクセスされているによって異なります。ページないアクセスされている場合の使用しない場合に-が期限切れすることもできます。一定の時間を超える使用取得しない場合、アイドル時間は、ページの有効期限-たとえば、10 または 20 分です。

絶対時間の有効期限がおそらく最も重要な Web ページの有効期限の時刻です。製品の Web キャッシュを使用するルールを指定してキャッシュにどの URL パターン ("URI"と呼ばれる) を選択できます。 Web キャッシュ特定の URL がキャッシュされるしないことを指定できます。特定の時間の特定の長さをキャッシュの URL の種類を指定することができます。

これは、必要がありますもできます時期、URL の出力に付属する HTTP ヘッダーで提供される情報に基づいてさまざまな URL の有効期限を指定します。すべてのページの HTTP ヘッダーはどのくらいの期間、キャッシュできるいません、情報を格納できる、期限切れとが場合最後に変更します。これは、項目は、キャッシュの確認ページのコンテンツが変更されたかどうかと、キャッシュに新しいコンテンツをアップロードする必要かどうかを監視する Web です。せず、この機能を無効にして、古いデータを削除することはありません。

有効期限の設定] ページの再読み込み

別の重要な機能が再自動的に読み込み、ページ、何らかの理由で期限が切れたかどうかによりする絶対またはアイドル時間の有効期限をられます。たとえば、発声可能性があります: このページはする場合、次の 20 分に適しています。 20 分後、Web キャッシュ自動的に re-fetches そのページ常に最新のコピーがあるできるようにします。

こうすると、しない待つユーザーにそのページから次の要求。 Web ファームからそのページを再度フェッチの遅延を通過するユーザーがする要求が表示されたら、されていないためにです。バックグラウンドでフェッチすることができます、ためそのする 5 ～ 10 秒かかりますまず実行して、Web サーバーからフェッチします。大丈夫をユーザーはそれを取得するまでができますが、sub-second の応答時間を返すため遠ユーザー方法に依存するためです。

部分ページキャッシュ

独自の URL である各複数項目を含めるの一部のブラウザーで表示されるページと。ように場合、ページをレンダリングするのには、Web ブラウザー呼び出して必要があります複数の URL。部分的なページと同じ結果を達成この — 各 URL、サーバー側で独立したページを表し、独立しておよびそのコンテンツの性質に応じて、異なる期間に各ページがキャッシュ部分的なページの呼び出さされませんがします。

状況によっては、単一 Web ページなどで開発された内容な方法に分割セクション。一部のセクションは静的と変更しない、一部は、別の間隔後を変更する各部分で動的です。実際には、部分ページキャッシュのキャッシュページのセクションに基づく静的または動的いるかどうかのキャッシュ期間が格納できるように、ページ全体をキャッシュだけでなく。

ASP.NET では、部分ページキャッシュ 2 つの手段を通じてをできます: 置換を post-cache し、キャッシュを制御します。このキャッシュを実行する特定の ASP.NET ページを変更する必要は両方。できない可能性独自開発リソースしたしないこの社内の ASP.NET アプリケーションを開発するしなかった場合。ただし、部分ページキャッシュでは、ASP.NET での各タイプの説明に従います。

部分ページキャッシュによりキャッシュされたコンテンツを格納するユーザーコントロールを作成し、ユーザーコントロールキャッシュ可能ないる ASP.NET を実行できます。これは、ユーザーコントロールとして、ページの一部にキャッシュするページが再実行、これらの部分は、キャッシュから取り出されるだけと再実行されないようにできます。部分だけ、ページのユーザーコントロールとして指定されていないとマークされていない"キャッシュが再実行:"

キャッシュ後の置換をページがキャッシュされるが「動的"または」キャッシュ不能"にいくつかの部分またはその中のフラグメントはマーク次に、このページが再実行すると、動的またはキャッシュ不能部分のみが実際に実行されます。残りのページは、キャッシュから取得され、キャッシュと動的の両方の部分を組み合わせて、ページの出力を取得します。

興味深いことに、部分ページキャッシュのみ実行できます、Web サーバーにします。そのため、一部のプログラミングが必要。 ASP.NET の場合に部分ページキャッシュはによって行われます決定する ASP.NET ページでのプログラミング — とどのようなない-キャッシュにします。このキャッシュは、Web サーバー自体に対して実行されますしても、少なくとも、ASP.NET ページを実行の一部です。

ASP.NET では、部分ページキャッシュは、マイクロソフトの仕様は、Java プラットフォーム上でのベースに実装、部分ページの標準と呼ばれるエッジサービスが含まれています (ESI) のキャッシュが出現します。 ESI は、コンテンツ配信ネットワーク、エンドユーザーのブラウザーまたはユーザーのブラウザーと Web サーバー間のリバースプロキシとして機能する Web キャッシュサーバー内にあるかどうか、集計、編成およびできるネットワークの端で配信キャッシュおよびキャッシュ不能の Web ページコンポーネントを定義する XML ベースの単純なマークアップ言語を定義します。

高度なプラットフォーム固有部分ページキャッシュは、-、もちろん、ASP.NET を使用してする必要がありますマイクロソフトの手法。

データベースの依存関係

別のキー機能は、ページが対応するときに、キャッシュから無効に出力できるデータベースの依存関係のデータがデータベース変更します。ページの出力は、データベース内のデータに基づいてを生成して多くの場合。これらを表すデータは、1 つまたは複数のデータベーステーブル内の 1 つ以上の行のものです。したがって、それらの行を変更する場合しこれらのページする必要がありますがキャッシュから削除します。そのため、データベースの同期は重要な機能です。つまり、データをデータベースに変更する、これらのページの出力無効化する必要があり、キャッシュから削除する必要があります。この機能では自動的に特定のページがキャッシュから削除される判断することができます。

この依存関係を作成するの 1 つの方法「選択」SQL ステートメント (SELECT ステートメントを含むストアドプロシージャ呼び出し) を指定することですいくつかの SQL ステートメントでパラメーターを持つページ GET または POST パラメーターをマップし、対象のページに対応します。実行時に、SQL ステートメントを実行するには、Web ページパラメーターを使用され、SqlCacheDependency が SQL Server 2005/2008年または Oracle 10 g R2 または以降のデータベースに対して作成されます。データベースに対応する行を変更、データベースサーバーは Web キャッシュサーバーによってキャプチャの .NET イベントを発生させます。対応する Web ページ出力がキャッシュから削除し、( 図 3 </a0> 参照)。

図 3 場合 Web キャッシュからページが削除データベース行の変更:

ファイルの依存関係

もう 1 つの主要機能は、ファイルの依存関係です。命令で、システムで、ページ出力をファイルに関連付けることがあります: 無効「このファイルはこれまでに更新または削除、くださいにこのページ」。 Web キャッシュは、共有フォルダーに保存されているそのファイル監視します。そのファイルが更新または削除しまった場合、Web キャッシュはキャッシュから対応する URL を自動的に無効します。これによりできますを更新する、システム内の任意の場所からファイルを別のアプリケーションまたはもいくつかの関連データの変更時に基づいて、データベースサーバーでトリガーが含まれますかどうか。たとえば、データが、SQL 2005/2008年または Oracle データベースではなく、メインフレームに格納されている場合は、ファイル依存関係、キャッシュページを無効にする使用できます。

すべてこれにより、キャッシュを通知することができます特定よう環境内、または、データストアでは、Web キャッシュによって直接アクセスする場合を無効にする場合。

PDF の部分的なコンテンツ

多くの人々 PDF ファイルをオンラインにアクセスするようになりました。一般的な利用状況パターンはことが 1 つのページ、一度に読み込む、PDF ファイルページで、全体の通過になります。いくつかのユーザー、全体の PDF をダウンロード、ローカル読み取り最もがブラウザーで読み取ること。それの一部から取得した後破棄が、情報のように表示されている時に、通常しない全体文書の読み取りです。

では、全体の PDF は、サービスを提供リソースを無駄では多くの場合、実際にピーク時に許容と許容のパフォーマンスの間で識別係数可能性があります。そのため、PDF 部分的なコンテンツの処理は、Web キャッシュに重要な機能です。 Web サーバー上で帯域幅負荷を軽減し、全体的なスケーラビリティを向上します。

ViewState のキャッシュ

ASP.NET で最も重要な機能の間では、サーバー上で実行し、同じページに post-back するコントロールを宣言する機能です。論理的には、1 つのページが属している別の操作を処理する複数のページの作成を終了するには、従来の ASP での ASP.NET の前に (たとえば、データの読み込み、データの保存やその他の操作を実行します。 ASP.NET では、できなくする必要はそうです。フォームフィールドおよびその他のコントロールここでは宣言できます、サーバーで実行する、そのサーバーページ自体をポストだけです。

これら post-backs を処理する、ViewState が作成され、コントロールとこれらのコントロールに割り当てられている動的な情報の ID を記録します。つまり、ViewState ページのコントロールの状態を複数のポスト間で保持します。

ViewState は、ASP.NET アプリケーションにとって重要です。基本的に、その送信情報、Web サーバーでブラウザーにブラウザー送信できるように、同じ情報サーバーに、次の時間ユーザーは、同じページに対する投稿します。

たとえば、[customer.aspx] ページで、顧客をロードすることがあります。するいくつかの変更で、顧客データを行いクリックして上書き保存します。 [保存] ボタンはもう一度 customer.aspx を呼び出しますが、customer.aspx このポストバックを処理する方法を知っているように、ViewState が送信されます。 customer.aspx が、ブラウザーに送信され、ポストバック新しいデータ、ユーザーが変更などが含まれている情報を ViewState に格納します。変更内容とそれについての対処を決定する customer.aspx をできます。これは単純な例だけなので、ViewState できます他動的に作成されたデータページのコントロールごとをも含まれます。

ViewState は、高度では、ASP.NET で便利ですが、データ転送前後 Web サーバーからユーザーのブラウザーにコストも実行します。このコストが、アプリケーションのユーザーが Web サーバーから遠く、低速のインターネット接続経由でのピーク負荷時に、パフォーマンスとスケーラビリティの影響があります。

しかし、ViewState Web キャッシュでキャッシュできる場合、ブラウザーのスライダーを移動する必要多くの場合、しません。その場合のタグのみまたは一意の ID でしたはブラウザーに送信付与を一意の ID。に基づいて、Web サーバーに戻して、ViewState Web キャッシュは再インストールし、ブラウザーが戻ると場合、ようにサーバーが必要なすべての Web が、次回のブラウザーが、要求を送信含まれる、以前の時刻から、ViewState です。ブラウザーがしない情報を使用するため、ViewState が、ブラウザーに達したかどうかもかまいません)、Web サーバーだけがします。

技術用語では、ViewState がこれまで post-backs を行う場合、ViewState には、必要があります、Web キャッシュは、ViewState をキャッシュできるされ、ポストバックの使用されます。保存かなりの帯域幅、ため、ViewState がサイズで少数のキロバイトします。

Gzip 圧縮

曜日は、ほとんどのブラウザーは gzip 圧縮コンテンツを展開することができます。ないすべての Web サーバーは自動的に Web ページの出力を圧縮する構成します。大量の高トラフィックによって既に負荷中は各 Web サーバーで不要な CPU を消費、圧縮がオンの場合でも. ただし場合、圧縮が中間プロキシ Web キャッシュサーバーによってよりスケーラブルななります。

方がしないを変更する静的データを圧縮する簡単です。ただし、ASP.NET アプリケーションでのほとんどのページが動的であり、ページ出力毎回を変更できない場合、コンテンツは圧縮だけ必要があります。それ以外の場合は、圧縮が、おそらく帯域幅の使用率の向上を dwarfing、CPU に負荷が正しくを配置します。 Web キャッシュが既にを考え出すに関するインテリジェントされているためする動的なページ出力がキャッシュ (意味の簡単な期間は、少なくとも 1 つ変わりません) をも自動的にキャッシュページを圧縮することです。これらのキャッシュされたページモードが処理されるクライアントに複数回圧縮形式でしかなり帯域幅の使用量を削減します。

コンテンツは既に圧縮されていない限り、一般的な gzip 圧縮約 80%、によって、コンテンツが減少 (たとえば、PDF、JPEG、TIFF など。)。適切な Web キャッシュは、ユーザーを圧縮する場合は、このチェックボックスをオンにする URL を指定および圧縮は無視するようにします。

スケーラブルで動的な Web キャッシュクラスター

Web キャッシュは (ほとんどの場合、アプライアンス) など、ASP.NET Web ファームの前面に表示されるサーバーです。今日に 100-plus、ロードバランサーサーバーに 2 台のサーバーから ASP.NET Web ファームできる拡張します。したがって、1 つの Web キャッシュサーバーは、日々の Web ファームの負荷を処理できません。適切な経験則なことです、ファーム内すべて 5 Web サーバーでする 1 つの Web キャッシュサーバー。

複数の Web キャッシュサーバーと、だけでなく、スケーラビリティの向上が Web キャッシュ 1 台のサーバーがダウンまたはが解除される、キャッシュが失われていないし、パフォーマンスの低下 (参照が存在しないようにをレプリケートすることができます。図 4 ).

図 4 動的な Web キャッシュクラスター (の追加や実行時にサーバーを削除):

適切な Web キャッシュサーバーレプリケーションを通して信頼性および複数サーバーによるスケーラビリティを処理する Web キャッシュサーバーのクラスターを構築できる必要があります。ただし多くの Web キャッシュ-サーバーが関連する 1 つの論理 Web キャッシュ考慮もです。でも、キャッシュ、クラスター内の複数のコピーがある、いる常に保持同期。つまり、Web キャッシュサーバーのクラスターを持つできます、キャッシュの論理的な正確さの維持しながらスケールします。

キャッシュクラスターを入手したら、適切な Web キャッシュトポロジのキャッシュとも呼ばれる、別のキャッシュに格納するオプションを指定すること必要があります。メインのトポロジは、キャッシュのレプリケートされた、キャッシュのパーティション分割クライアントキャッシュなどがあります。

キャッシュ手段が、全体のキャッシュがクラスター内の各のキャッシュサーバーにコピーをレプリケートします。その結果、各キャッシュサーバーは、全体のキャッシュをいます。すべての「取得」操作は常にそのボックスにローカルし非常に高速を結果としてには。ただし、複数のキャッシュサーバーに更新が加えられるし、クラスターにこのような 3 つ以上のサーバーがある場合の [更新コスト増加します。

その一方で、キャッシュのパーティション分割 (またはパーティション) を別のキャッシュサーバーに各パーティションを格納する、キャッシュパーティションの数がキャッシュサーバーの数と等しい。これによって、レプリケートされたキャッシュで行うことはできませんが、以上のキャッシュサーバーを追加してキャッシュの容量を増加できます。パーティションキャッシュでは、キャッシュがそれらのサーバーの停止した場合失わないように、異なるキャッシュサーバー上の各パーティションのバックアップを作成することもできます。パーティションのキャッシュはストレージおよび 1 秒あたりのトランザクションの両方の最もスケーラブルなキャッシュトポロジです。

最後に、クライアントキャッシュは、トポロジが組み合わされて Partitioned とキャッシュのレプリケートされたか、(特に、実際のキャッシュが、Web キャッシュサーバー以外のサーバーでホストされている) 場合です。クライアントキャッシュは、頻繁に使用されるデータを常に使用できるように終了によって、キャッシュクライアントプロセス内の小さなサブセットを保持します。クライアントキャッシュの保存とフェッチ最近どのようなクライアントによって異なります。最大サイズは新規のクライアントキャッシュとそのサイズに達すると、領域を確保する古いアイテムを削除 (または削除) に開始するための指定できます。これにより、クライアントキャッシュしない消費より多くのメモリ実現が判断したものよりもします。

キャッシュクラスターを作成しないでを複数の Web キャッシュサーバーを使用する場合、キャッシュの切断されたコピーを複数最終的されます。その結果、Web サイトが比較的静的でが動的な Web サイトと ASP.NET アプリケーションでは、データ整合性の問題がありますが場合は許容範囲があります。さらに、する最後別の Web キャッシュサーバーが、キャッシュ内のこのページの出力であるにもかかわらず、ユーザーの要求を Web サーバーに送信することにより、ASP.NET Web ファーム上の負荷を増加します。

地理的なキャッシュの配布

多くの ASP.NET アプリケーション Web サイト現在ユーザーがいる世界中場合でも、Web サイト自体が 1 つの場所でホストします。複雑さと、インフラストラクチャのコストのための複数の地理的な場所に配置 Web サイトのこと不可能です、多くの場合。たとえば、ASP.NET Web ファームは、同じ場所にデータベースサーバーがあるにも、高いトランザクションアプリケーションを含む、場合、データベースサーバーは通常、地理的な配布に適してされません。その結果、エンドユーザーがワイドエリアネットワーク (WAN) の遅延のため、パフォーマンスが低下を発生します。

1 つする方法この問題を解決することです、地理的な各場所に Web キャッシュサーバーを配置し、最も近い Web キャッシュサーバーを経由する領域からすべてのトラフィックをルーティング ( 図 5 </a0> 参照)。 [Web キャッシュサーバーは既にキャッシュページがない、直接、要求を送信、メインデータセンター、Web キャッシュサーバーの別のセットが置か。

図 5 での Web キャッシュサーバーは地理的に分散環境。

したがって、適切な Web キャッシュには各 Web キャッシュはキャッシュページインストールされていない場合でも、要求をルーティングする場所を知っているように、サーバーの階層を作成できるがあります。

データベースの外からの維持します。

定数ままデータを毎回変わらない [2009年 6 月資料で説明した、ようです。残念ながら、分散キャッシュ、なしと繰り返し同じデータを再現する不要なサイクルを通じて実行します。しないすべての時間をデータベースに移動します。同じデータ、ため理由移動がでしょうか。その理由は、キャッシュからためでしょうか。

ここでは、この問題を強調表示例です。航空会社のメインの Web ページがない多くの変更; を長時間キャッシュできます。顧客訪問フライトを検索します。バックエンドでの情報を変更する座席を予約した他のユーザーとしてため、情報がシフト常にします。

顧客は、検索、フライトニューヨークからサンフランシスコと結果か座席可用性にによって決まります。座席の可用性は、予約された既に予約が絶えず行われるとユーザーの数に基づきます。 harried、businessperson 誤った情報を入力または座席の割り当てを確実に複数のエントリの作成によって問題複雑になります可能性があります。

ユーザーは、その情報を 5 分ごとにキャッシュに変更を特定のフライトが、利用可能なことを示す結果を受け取ります。顧客は、実際には、座席を予約しようと、いったんし、リアルタイムチェックは実行、データベース内。なぜならすべて 1, 000 人だけで約 10 が実際に、予約を行う可能性がありますフライトの可用性の確認します。提供された情報が正しく完全ない可能性がありますにもかかわらず、すべての利用者にフライトの可用性を表示する問題です。このような状況は、高度な動的の場合もそのページをキャッシュできます。

ない完全に正確でいくつかのリスクと情報を提供するので、アイデアをキャッシュすることができます。ただし、[引当] ページで、データベースに、重要ですすべての情報が正確で最新の状態。ここではことすべてのアプリケーションにはキャッシュできる一般的な情報がられており、Web サイトのユーザーはたびに、航空会社のデータベースに送信する必要はありません。

最も簡単な段階は、すべてのイメージをキャッシュするたい場合です。会社のロゴや、社長の画像または標準のドキュメントをユーザーに読み取り可能なが既に変更しません。次より動的ないる他の部分があります。場所の規則を指定できますと言うたとえば、「この長いのこのページをキャッシュをする」

その他のページを言ってが、"わからない期間のする、キャッシュするデータベースに関連付けるします。このテーブルの行はこの変更された場合するこのページが無効に" つまり、キャッシュから削除し、新しいコピーを作成、再読み込み追加し。各ページのカテゴリが異なります。 Web キャッシュを使用してページをキャッシュする方法を決定できます、限りはキャッシュするほど、Web ファームに移動する、小さいを状況を作成します。

ガイドライン

ほとんどの場合は Web キャッシュを展開して重要な利点を実現できます。 1 つの Web サーバーだけが既に、可能性は十分なトラフィック種の問題が発生する必要はありません。負荷分散された Web ファームが既に 1, 000 以上のユーザーを取得する場合。その場合は、パフォーマンスとスケーラビリティを最適化する方法について学習するため、候補できました。

前もって計画します。しないパニックモードには、その後に発生する問題を待ちます。最適な時間は、重大な問題を見開きいないときになどがその時点で、する必要がありますできるようなプロジェクトの資金を要求する理由について経営陣を納得させます。その目標を達成する優れた一: 管理とその可能性がありますコスト自社場合、Web サイト [あたり 30 ～ 60 秒) の upward のピーク時の painfully 低速応答時間を確認します。され場合、Web サイト異常 30 ～ 60 分のでしょうか。それらの質問を検討して、Web キャッシュの必要性について組織の経営陣を納得させるのに役立ちます。

以前メモしておいた、として無料と両方商用 Web キャッシュのオプションが使用可能です。開発者間で増大の人気を ASP.NET の .NET をサポートする業者の Web キャッシュオプションは新興ようになりました。ただし、現時点でほとんどの Web キャッシュの製品サポート Java と PHP。ほとんどソフトウェアベースでは一部のハードウェアアプライアンスオプションはなく利用可能です。

選択内容を考慮すると、組織と Web サイトでフォーカスのあるままです。動的な方法は、サイトですか。ユーザーは何人いますか? どの程度のキャッシュに本当に役立つされるでしょうか。

必要などのようなキャッシュ機能を検討します。ここまで説明したようには、blazingly 高速でスケーラブルなトランザクションはキャッシュします。ユーザーの古い情報をことがあります得、ことができます。その残高に注意してくださいをまま、さまざまなソリューションを検討します。

Iqbal ハーン社長とのテクノロジエバンジェリスト Alachisoft. Alachisoft は、パフォーマンスとスケーラビリティを上げるの先頭を ASP.NET キャッシュである NWebCache を示します。 Iqbal、M.S. を受信します。 1990 でインディアナ大学、Bloomington、コンピューターサイエンスの角度です。彼にアクセスできます。 iqbal@alachisoft.com.

その他のリソース