自動リフレッシュおよびプリロードのためのキャッシュ・エージェントの構成

ほとんどの Caching Proxy サーバーは、ユーザーがファイルを要求した後でそのファイルをキャッシュに入れるだけです。Caching Proxy には、自動キャッシュ・プリロードを行うキャッシュ・エージェントがあります。 キャッシュ・エージェントが、指定された URL または最も頻繁にアクセス される URL、あるいはその両方を自動的に検索し、これらの URL が要求される前に これらをキャッシュに入れるように指定することができます。

場合によっては、プロキシー・サーバーのホスト名を設定して、キャッシュをプリロードする前にキャッシュ・アクセス・ログを識別する必要があります。 キャッシュ・エージェントを構成するには、「構成および管理」フォームで、 「キャッシュ構成」を選択し、「キャッシュ・ プリロード」および「キャッシュ・リフレッシュ」フォームを 使用してください。照会の結果を表すファイル (すなわち、その URL に疑問符文字 (?) が 含まれているファイル) がキャッシュに入れられるのは、照会キャッシュが使用可能な 場合だけであることに注意してください。

自動キャッシュ・リフレッシュおよびプリロードには、以下の利点があります。

欠点としては次のものがあげられます。

効率を最適にするために、キャッシュ・エージェントを、サーバーの活動が少ないときや、クライアントの要求でビジーになる前に実行するように設定してください。 その場合、ユーザーがはじめてファイルを要求したときに高速に実行できるように、キャッシュ内でファイルが使用可能状態になっています。 デフォルトでは、キャッシュ・エージェントは、毎日、地方時の午前 3 時に開始します。

リバース・プロキシー構成の特別な考慮事項

リバース・プロキシー構成を使用するときは、 デフォルトで Proxy http:* ルールを無効にしてください。 これは、セキュリティー上の理由で必要となります。 (すなわち、このルールは ibmproxy.conf ファイル内でコメント化されます。) ただし、このルールを無効にすると、キャッシュ・エージェントは、 要求の送信や Caching Proxy のキャッシュ内容のリフレッシュを、 正常に行うことができなくなります。 エラー・ログに「403 Forbidden By Rule Error」が示され、 キャッシュのリフレッシュが完了しません。

この問題を回避するには、cacheAgentService を使用します。 これは、Caching Proxy が提供している内部サービスです。 このサービスを有効にするには、 ibmproxy.conf ファイルのその他のマッピング・ルールの前に、 次の Service ディレクティブを書き込みます。

Service   /any-valid-string*  INTERNAL:cacheAgentService

any-valid-string 変数は、 ibmproxy.conf ファイルの他のマッピング・ルールと競合しない、有効な任意のストリングです。

Caching Proxy およびキャッシュ・エージェントの両方が、 このサービス・ディレクティブを基にして URI の解析を行います。 URI を直接 Caching Proxy に送信する代わりに、 キャッシュ・エージェント・ユーティリティーは、 このサービス・ディレクティブで URI の前に /any-valid-string パターンを付加します。

例えば、キャッシュ・エージェントは、以下の URI

http://www.ibm.com/

を次のものに変換します。

/any-valid-string/http://www.ibm.com/

キャッシュ・エージェントは、この接頭部の付いた URI を Caching Proxy に送信します。 Caching Proxy は、この要求を受け取ると、 接頭部 /any-valid-string/ を除去します。 残りの URI が完全修飾されたユニットになっていれば、 Caching Proxy は、他のルールに対して URI をマッピングすることなく、 この要求にサービスを直接提供します。

さらに、キャッシュ・エージェントは、 関連する URI を Caching Proxy に送信することもできます。 例えば、ibmproxy.conf ファイルで前に参照したサービス・ディレクティブを使用して、 LoadURL /abc/ を追加すると、 キャッシュ・エージェントはそれを /any-valid-string/abc/ に変換し、 Caching Proxy に送信します。 Caching Proxy は URL を受け取ると、 接頭部を除去し、他のマッピング・ルールに対して /abc/ をマップし、一致がある場合はその要求を処理します。

Service ディレクティブについては、Service - サービス・ステップをカスタマイズするを参照してください。

サーバーのホスト名の設定

Linux および UNIX プラットフォームでは、 キャッシュがプリロードまたはリフレッシュされるプロキシー・サーバーの ホスト名を指定します。 Windows プラットフォームでは、リフレッシュされるプロキシー・サーバーがローカル・マシン上にない 場合だけホスト名を指定してください。(ローカル・キャッシュ・エージェントはリモート・サーバーの キャッシュ・アクセス・ログにアクセスしないので、頻繁にアクセスするファイルに基づいてリモート・ サーバーのキャッシュをリフレッシュすることはできないことに注意してください。)

プロキシー・サーバーのホスト名を設定するには、「構成および管理」フォームで、「キャッシュ構成」–>「キャッシュ・リフレッシュ」の「キャッシュ宛先サーバーの識別」を選択します。

キャッシュへの特定のファイルのプリロード

キャッシュに特定の URL に保管されているコンテンツをプリロードするには、「構成および管理」フォームで、 「キャッシュ構成」–>「キャッシュ・プリロード」を使用します。 このフォームで、キャッシュ・エージェントがロードする URL を指定できます。 プロキシーは、そのページが以前にキャッシュされていたかどうかに関係なく、 キャッシュ・エージェントの開始時にそのページを検索します (これら の URL は、LoadURL ディレクティブによってプロキシー構成ファイルに指定されます)。 また、このフォームは、そのコンテンツをキャッシュに入れない URL を定義する場合にも使用できます。 このタイプのキャッシュ・プリロードでは、キャッシュ・アクセス・ログへのアクセスは不要です。

キャッシュ・プリロード」フォームを使用して、次のオプションを構成します。

キャッシュへの頻繁にキャッシュされるファイルのプリロード

最もアクセス頻度の高いページを自動的にプリロードするには、「キャッシュ構成」–>「キャッシュ・リフレッシュ」フォームを使用します。 この機能には、プロキシー・サーバーのキャッシュ・アクセス・ログが必要です。 (ログの位置と名前は変更可能です。Caching Proxy のモニターを参照してください。) 頻繁にアクセス される URL は、キャッシュ・アクセス・ログから自動的に判別されます。管理者は、キャッシュにプリロードする頻繁にアクセスされるページの数を指定することもできます。(この数は LoadTopCached ディレクティブによってプロキシー構成ファイルに指定されます。)

キャッシュ・リフレッシュ」フォームを使用して、次のオプションを構成します。

探求

探求 とは、自動キャッシュ・リフレッシュ機能のうちのオプション部分です。ほとんどの Web ページには、関連情報を含んでいる他のページへのリンクがあり、ユーザーは、通常、あるページから別のページへとリンクしたり、あるサイトから別のサイトへとリンクするパスを たどります。探求は、このような論理情報パスをキャッシュに入れる手段となります。探求機能では、キャッシュ・エージェントは、ロードするページの指定されたレベルのハイパーテキスト (HTML) リンクをたどって、そのリンク・ページすべてをキャッシュに入れます。 リンクされたページは、ソース・ページと同じホストに常駐する場合でも、他のホストに常駐する場合でもかまいません。図 1 でこのことについて説明します。

図 1. 探求
探求

探求プロセスを制御するために、管理者はキャッシュ・エージェントにロードできる URL の最大数 (デフォルトの設定は 2000)、実行可能な最長時間 (デフォルトの設定は 2 時間)、および使用できるスレッドの最大数 (デフォルトの設定は 4) を指定します。 管理者は追加の制御も構成することができます。 デフォルトでは、探求機能は 2 レベルの階層で使用可能になっていますが、ホスト間では許可されません。 さらに、要求間に遅延を挿入します。 これらの設定値を変更するには、関連したプロキシー構成ファイル・ディレクティブを参照してください。

キャッシュ・エージェントは、以下の順序でキャッシュをロードしたあと、リフレッシュします。

  1. 管理者が指定した特定のページをロードします。
  2. キャッシュ・アクセス・ログの一般的な (頻繁にアクセスされる) ページをロードします。
  3. この時点で最大ページ数に達していない場合には、探求機能によって追加のページがロードされます。

キャッシュ・エージェントは、リンク間の探求を開始するまではページの最大数に既に達して いるかどうかについて検査しません。ページ数の最大値 (プロキシー構成ファイル内 で MaxURL と呼ばれる) がステップ 1 および 2 で検索されるページの数より 小さい場合は、リンクされたページはまったく検索されません。

以下の例は、指定された URL の最大数に関連して、キャッシュ・エージェントがキャッシュ・リフレッシュの優先順位と探求をどのように処理するかを示しています (以下の例すべてに探求機能が構成されているものとします)。

構成ファイルの設定 結果
LoadURL  
 http://www.getthis.com/main.html
LoadURL  
 http://www.getmetoo.com/welcome.htm
LoadTopCached 30
MaxURLs 50
キャッシュ・アクセス・ログに 31 以上の固有の URL がある場合、キャッシュ・エージェント は、main.html と welcome.htm を検索し、キャッシュ ・アクセス・ログに基づいた上位 30 の要求された URL を検索します。 MaxURL 値にはまだ達していないので、キャッシュ・エージェントは、リンクされた URL を最大 18 まで、既にキャッシュに格納されているページから検索してロードします。
LoadURL  
 http://ww.joesmith.edu/favorites.html
LoadURL
 http://www.janesmith.edu/dislikes.html
LoadTopCached 30
MaxURLs 25
キャッシュ・アクセス・ログに 31 以上の固有の URL がある場合、キャッシュ・エージェント は、favorites.html と dislikes.html を検索し、キャッシュ・アクセス・ログから上位 30 の要求された URL を検索します。 MaxURL の値を既に超えているので、その他のファイルは検索されません。
LoadURL http://www.hello.com/hi.htm
LoadURL  
 http://www.ballyhoo.com/index.html
LoadTopCached 20
MaxURLs 25
キャッシュ・アクセス・ログに 21 以上の固有の URL がある場合、キャッシュ・エージェント は、hi.htm と index.html を検索し、キャッシュ・ アクセス・ログから上位 20 の要求された URL、および以前のページから最高 3 つまでのリンク された URL を検索します。MaxURL の値に既に達しているので、その他のファイルは検索されません。

関連したプロキシー構成ファイル・ディレクティブ

キャッシュ・エージェントは、プロキシー構成ファイルで適切なディレクティブを直接編集して構成することもできます。キャッシュ・エージェントに関連したプロキシー構成ファイルのディレクティブについては、付録B. 構成ファイル・ディレクティブの以下の解説ページを参照してください。

キャッシュ・エージェントの手動による開始

自動キャッシュ・リフレッシュが使用可能になっていると、キャッシュ・エージェントは 指定された時刻に自動的にリフレッシュ操作を実行します。 しかし、キャッシュ・エージェントは、任意の時刻にコマンド行から実行することもできます。

実行可能ファイルは、次のとおりです。

Linux および UNIX プラットフォームでは、 cron デーモンを使用することにより、 さまざまな時刻にキャッシュ・エージェントを自動的に実行できます。 cron で制御されるジョブは、システムの crontab ファイルに行を追加することによって指定します。 次に、Linux および UNIX 上のコマンド・ファイルの項目の例を示します。

45 16 * * * /usr/sbin/cacheagt

このコマンド例は、地方時で毎日の午後 4 時 45 分にキャッシュ・エージェントを 開始します。複数の項目を使用して、希望すれば、複数回キャッシュ・エージェントを実行することができます。詳しくは、使用しているオペレーティング・システムの資料で cron デーモンについて参照してください。

cron デーモンを使用してキャッシュ・エージェントを実行する場合には、 「キャッシュ構成」–>「キャッシュ・リフレッシュ」構成フォームを 使用するか、またはプロキシー構成ファイルを編集して、自動リフレッシュ・オプションをオフにすることを 忘れないでください。そうしないと、キャッシュ・エージェントが毎日複数回実行されることになります。