一般に、全体的なパフォーマンスのためには、 個々のハードウェアを追加するだけではなく、 アーキテクチャーを調整することが得策です。 単一のマシンにハードウェアをいくつ追加するとしても、 そのハードウェアにはパフォーマンスの最大レベルが存在します。
このセクションでは、 ネットワークに Caching Proxy 機能を導入するときに考慮するべきネットワーク・アーキテクチャーの問題について説明します。
企業の Web サイトの人気がある場合、単一の プロキシー によって効率的に処理できる量を超える要求がコンテンツに対して寄せられて、応答時間が長くなることがあります。 ネットワーク・パフォーマンスを最適化するには、クラスター化されてロード・バランシングが行われる Caching Proxy マシンを組み込むか、ネットワーク・アーキテクチャー全体でリモート・キャッシュ・アクセス (RCA) を用いた共有キャッシュ・アーキテクチャーを使用することを検討してください。
アーキテクチャーを調整する 1 つの方法は、プロキシー をクラスター化して Load Balancer コンポーネントを使用し、負荷のバランスを取ることです。 プロキシー のクラスター化は、パフォーマンスとスケーラビリティーを向上させるためだけではなく、冗長度と信頼性の問題を解決する上でも有益な設計上の考慮事項です。 単一の プロキシー は Single Point of Failure (SPOF) になります。すなわち、プロキシー・サーバーに障害が発生するか、ネットワーク障害が原因でアクセス不能になった場合、ユーザーは Web サイトにアクセスできなくなります。
RCA を使用した共有キャッシュ・アーキテクチャーの使用も考慮してください。 共有キャッシュ・アーキテクチャーでは、全体の仮想キャッシュが複数の Caching Proxy サーバーに広げられ、それらのサーバーでは、通常、Internet Cache Protocol (ICP) または Cache Array Routing Protocol (CARP) などのキャッシュ間プロトコルが使用されます。 RCA は、大規模な仮想キャッシュの提供によって、 クラスター化されたキャッシュのヒット率を最大化することを目的に設計されています。
プロキシー の RCA 配列を使用すると、単一のスタンドアロン Caching Proxy だけではなく、スタンドアロン Caching Proxy マシンのクラスターに比較しても、パフォーマンスが向上します。 パフォーマンスは、主として合計仮想キャッシュ・サイズを増加ずることによって向上します。 これにより、キャッシュ・ヒット率が最大になり、キャッシュの不一致と待ち時間が最小になります。 RCA を使用すると、特定の文書の 1 つのコピーのみがキャッシュに入れられます。 プロキシー のクラスターを使用すると、合計キャッシュ・サイズは大きくなりますが、複数のプロキシー・サーバーが同じ情報をフェッチしたりキャッシュに入れたりする可能性があります。 このため、合計キャッシュ・ヒット率は高くなりません。
一般的に、RCA は大規模企業のコンテンツ・ホスティングのシナリオで使用されます。 ただし、RCA の有用性は、非常に大規模な企業での展開に限定されるものではありません。 ネットワークの負荷がキャッシュ・サーバーのクラスターを必要とする場合、 および要求の多くがキャッシュ・ヒットの場合に、RCA の使用を考慮してください。 ネットワークの設定によっては、RCA が構成されると クライアントが使用する TCP 接続の数が増えるため、RCA が常に企業のパフォーマンスを向上させるとは限りません。 これは、RCA メンバーが最高スコアの URL の提供を担当するだけではなく、 最高スコアではない URL の要求を受けた場合に他のメンバーまたはクラスターに要求を送信する必要もあるからです。 これは、RCA 配列の任意の指定されたメンバーが、スタンドアロン・サーバーとして作動する場合よりも より多くのオープン TCP 接続を持つ可能性があることを意味します。
パフォーマンスは、主に Caching Proxy のキャッシング能力によって向上します。 ただし、プロキシー のキャッシュは、正しく構成されていないとボトルネックになる可能性があります。 最良のキャッシュ構成を判別するには、 トラフィックの特性の分析に力を注がなければなりません。 コンテンツのタイプ、サイズ、量、および属性は、起点サーバーから文書を取り出すための時間とサーバーにかかる負荷の点で、プロキシー のパフォーマンスに影響を与えます。 Caching Proxy が代理するかキャッシュから供給するトラフィックのタイプを理解していると、プロキシー を構成するときにそれらの特性を考慮に入れることができます。 例えば、キャッシュに入れられるオブジェクトの 80% がイメージ (*.gif または *.jpg) であり、 そのサイズが約 200 KB であることが判別できれば、 キャッシング・パラメーターのチューニングと キャッシュのサイズの決定に間違いなく役立ちます。 さらに、コンテンツの多くが、キャッシングの対象にならないパーソナライズされた動的ページであることを理解することも、Caching Proxy のチューニングに関連します。
トラフィック特性の分析を行うと、 メモリー・キャッシュとディスク・キャッシュのどちらを 使用するとキャッシュのパフォーマンスを最適化できるかを 判別することができます。 また、ネットワークのトラフィックの特性に精通すると、Caching Proxy の動的キャッシング機能の使用によってパフォーマンスが向上するかどうかを判別できるようになります。
ディスク・キャッシュは、大量の情報をキャッシュに入れるサイトに適しています。 例えば、サイト・コンテンツが 5 GB を超えるほど大きく、 キャッシュ・ヒット率が 80% から 90% までの場合は、 ディスク・キャッシュが推奨されます。 ただし、メモリー (RAM) キャッシュを使用すれば処理速度は上がり、 メモリー専用キャッシュを使用することが大規模サイトに適している というケースが多数存在することも明らかです。 例えば、Caching Proxy のキャッシュ・ヒット率があまり重要ではない場合か、 共有キャッシュ構成が使用されている場合には、 メモリー・キャッシュが現実的な選択になります。
Caching Proxy は、Application Server キャッシュの仮想拡張をネットワーク・ベースのキャッシュに対して提供し、WebSphere® Application Server の動的キャッシュによって生成された動的コンテンツ (JSP およびサーブレットの結果) をキャッシュに入れたり無効にしたりできます。 動的に生成されたコンテンツのキャッシングを使用可能にすると、 アプリケーション・ロジックまたはデータベースからのメッセージなどのイベントによって有効期限が切れる、 動的に生成された公開 Web ページへの要求が多い環境でのネットワーク・パフォーマンスが向上します。 ページの存続時間は有限ですが、 有効期限トリガーを作成時に設定することはできません。 このため、動的キャッシングおよび無効化機能のないホストは、 そのようなページの存続時間値をゼロと指定しなければなりません。
動的に生成されたこのようなページが 存続時間中に 1 人以上のユーザーから複数回要求される場合、 動的キャッシングによってオフロードが行われ、 ネットワークのコンテンツ・ホストに対するワークロードを削減します。 動的キャッシングを使用すると、インターネットの横断がより少なくなるために ネットワークの遅延が除去されて帯域幅の使用量が削減され、ユーザーへの応答が より高速になり、ネットワーク・パフォーマンスも向上します。