JPH09204347A

JPH09204347A - ゲートウェイ装置

Info

Publication number: JPH09204347A
Application number: JP8307749A
Authority: JP
Inventors: Hiroyoshi Toda; 浩義戸田; Katsuyoshi Doi; 克良土居
Original assignee: Sharp Corp
Current assignee: Sharp Corp
Priority date: 1995-11-20
Filing date: 1996-11-19
Publication date: 1997-08-05
Anticipated expiration: 2016-11-19
Also published as: JP3386964B2

Abstract

(57)【要約】【課題】キャッシュファイルを新鮮に保ちながら、キ
ャッシュヒット率の向上したproxy サーバ装置を提供す
る。【解決手段】キャッシュファイル１６を使用し、アク
セスログ１５を書出す第１のproxy プロセス１４に加え
て、アクセスログ１５から、キャッシュファイル１６の
有効期限よりも長い期間内のアクセスログを抽出し、ア
クセスリスト３０を作成し、定期的にこのリスト３０内
のファイルオブジェクトへのアクセス要求を発行するプ
リフェッチプロセス３６と、このアクセス要求に応答し
て外部サーバからファイルオブジェクトを取得しキャッ
シュファイル１６に格納するための第２のproxy プロセ
ス３４とを含む。第２のproxy プロセス３４は複数個同
時に実行されてもよく、この際に優先度を第１のproxy
プロセスより低くすると好都合である。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワーク上に
分散した複数のサーバ計算機と、複数のクライアント計
算機とがゲートウェイ装置（計算機）を介して通信回線
で相互接続されている分散ファイルシステムに関し、特
に、複数のクライアント計算機が、ゲートウェイ計算機
を介してサーバ計算機内部の記憶装置内のファイルオブ
ジェクトにアクセスする場合の分散ファイルシステムの
ファイル中継を行なうゲートウェイ装置に関する。

【０００２】

【従来の技術】以下の説明中で「サーバ計算機」とは、
ネットワーク上において何らかのサービスを提供してい
る計算機をいい、「クライアント計算機」とは、そうし
たサーバ計算機のサービスを要求し、受ける計算機をい
うものとする。また「ファイルオブジェクト」とは、フ
ァイルシステムの利用するネットワークプロトコルと、
ネットワークアドレス（サーバ計算機の名称）と、ファ
イル名称と、ファイルの実体との組をいうものとする。
ここで「ファイルオブジェクトの名称」とは、ネットワ
ークプロトコルとネットワークアドレスとファイル名称
との組のことをいう。

【０００３】従来、上述したような分散ファイルシステ
ムにおいては、複数のクライアント計算機からのサーバ
計算機上のファイルオブジェクトに対する読出要求は、
一旦途中のゲートウェイ計算機で中継されていた。ゲー
トウェイ計算機がサーバ計算機から読出したファイルオ
ブジェクトは、クライアント計算機に中継される。それ
と同時にそれらファイルオブジェクトは、ゲートウェイ
計算機内部のキャッシュファイル（固定ディスク、半導
体メモリなど）に蓄積される。そうしたゲートウェイ計
算機の一例が特開平４−３１３１２６号公報（発明の名
称「分散ファイルシステムのファイル入出力方式」）に
開示されている。

【０００４】図１２を参照して、この従来技術に開示さ
れたシステムは、ゲートウェイ計算機１１０と、このゲ
ートウェイ計算機１１０を介して相互に接続されたサー
バ計算機１００および複数のクライアント計算機１２０
を含む。サーバ計算機１００は、複数のクライアント計
算機１２０によって共有されている。

【０００５】サーバ計算機１００は、ファイルを格納す
るディスク装置１３６と、ネットワークを介してディス
ク装置１３６のファイルの内容を入出力するためのファ
イル入出力応答手段１３４と、ディスク装置１３６内の
ブロック情報をネットワークを介してクライアント計算
機１２０に応答するためのブロック情報応答手段１３２
とを含む。

【０００６】クライアント計算機１２０は、サーバ計算
機１００のブロック情報応答手段１３２に対してブロッ
ク情報要求を送り、ブロック情報を受けるためのブロッ
ク情報要求手段１５２と、ゲートウェイ計算機１１０を
介してサーバ計算機１００のファイル入出力応答手段１
３４に対してファイル入出力要求を送り、当該ファイル
を受信するためのファイル入出力要求手段１５４とを含
む。

【０００７】ゲートウェイ計算機１１０は、クライアン
ト計算機１２０（複数）とサーバ計算機１００との間に
介在し、サーバ計算機１００内のディスク装置１３６
と、各クライアント計算機１２０との間のキャッシュメ
モリとして機能するものであり、キャッシュした内容を
格納するためのディスクキャッシュ１４４と、ファイル
入出力要求手段１５４およびファイル入出力応答手段１
３４の間に介在するキャッシュ管理手段１４２とを含
む。

【０００８】図１２を参照して、このシステムは次のよ
うに動作する。まず、クライアント計算機１２０がサー
バ計算機１００内のディスク装置１３６中のファイルに
アクセスして１つのブロックを読込む場合の動作につい
て説明する。ブロック情報要求手段１５０は、ゲートウ
ェイ計算機１１０を介してサーバ計算機１００に対して
読込対象のブロックにかかるブロック情報の取得を要求
するブロック情報要求メッセージを発行する。

【０００９】サーバ計算機１００内のブロック情報応答
手段１３２は、このメッセージに応答して、ディスク装
置１３６から該当するブロック情報を取出し、そのブロ
ック情報を有するブロック情報応答メッセージをゲート
ウェイ計算機１１０を介してクライアント計算機１２０
内のブロック情報要求手段１５２に返却する。

【００１０】クライアント計算機１２０のファイル入出
力要求手段１５０は、返却されたブロック情報に基づい
て、読込対象のブロックの読込を要求するファイルアク
セス要求を、ゲートウェイ計算機１１０内のキャッシュ
管理手段１４２に対して発行する。

【００１１】このファイルアクセス要求を受取ったキャ
ッシュ管理手段１４２は、そのファイルアクセス要求に
かかるブロック情報と、ディスクキャッシュ１４４に記
憶されている読込対象のブロックにかかるブロック情報
との比較を行なう。そしてディスクキャッシュ１４４
に、該当するブロック情報が存在しない場合、または両
方のブロック情報の内容（更新時刻）が異なる場合（読
込対象のブロックのキャッシュが有効でない場合）に
は、キャッシュ管理手段１４２は上述のファイルアクセ
ス要求をサーバ計算機１００のファイル入出力応答手段
１３４に対して発行する。

【００１２】サーバ計算機１００のファイル入出力応答
手段１３４は、このファイルアクセス要求に応答して、
ディスク装置１３６内のファイルをアクセスして、該当
するブロックを読込み、ゲートウェイ計算機１１０にそ
のブロックを転送する。

【００１３】キャッシュ管理手段１４２は、このブロッ
クをディスクキャッシュ１４４に格納し、そのブロック
にかかるブロック情報のディスクキャッシュ１４４への
設定または更新を行なう。キャッシュ管理手段１４２は
同時に、そのブロックをクライアント計算機１２０のフ
ァイル入出力要求手段１５４に対して転送する。

【００１４】以上でディスクキャッシュ１４４内に有効
なファイルが存在しない場合のこのシステムの動作につ
いて説明した。

【００１５】次回に同一ファイルに対するアクセス要求
があった場合には、ゲートウェイ計算機１１０のキャッ
シュ管理手段１４２は、ディスクキャッシュ１４４から
当該ブロックを取出し、アクセス要求を発行したクライ
アント計算機１２０のファイル入出力要求手段１５４に
対して当該ブロックを転送する。したがってこの場合、
ゲートウェイ計算機１１０からサーバ計算機１００に対
する転送要求は発行されない。したがって中継アクセス
の高速化が図られる。

【００１６】類似の技術が、特開昭６３−２００２４４
号公報（発明の名称「ファイル・アクセス・システ
ム」）や、特開昭６３−２０１８４号公報（発明の名称
「遠隔ファイル・アクセス・システム」）にも開示され
ている。いずれの技術においても、あるファイルオブジ
ェクトに対するアクセス要求が発行された場合に、当該
ファイルオブジェクトの内容が更新されているかどうか
を確認するために、サーバ計算機の保持するファイルオ
ブジェクトの変更時刻をキャッシュファイルの変更時刻
と比較する。そしてキャッシュファイルの内容が古い場
合には、クライアント計算機は更新されたサーバ計算機
の内容を読出すようになっている。しかしこれら２件の
公報に記載された技術では、キャッシュファイルはクラ
イアント計算機内に存在しており、特開平４−３１３１
２６号公報に開示されたシステムのようにシステム内に
ゲートウェイ計算機が含まれているわけではない。

【００１７】しかしこれら３件の従来技術文献は、サー
バ計算機のファイルオブジェクトと、キャッシュされた
ファイルオブジェクトとの内容が食い違わないような工
夫をしているという共通点を持っている。

【００１８】このように本来同一であるべきファイルの
食い違いを防ぐことをインテグリティ（Integrity ）を
保つという。また、食い違いの起きたファイルのデータ
をステールデータ（stale data）と呼ぶ。

【００１９】上述した従来の技術の基本は、ネットワー
ク経由でサーバ計算機の、該当するファイルオブジェク
トの変更時刻を調べ、対応するキャッシュファイルの内
容の変更時刻と比較するアルゴリズムを使用している。
そのためサーバ計算機に対するネットワーク経由の問合
せを必ず行なわなければならない。ネットワークの実効
的な転送速度が小さい場合や、該当するファイルオブジ
ェクトを有するサーバ計算機にかかっている負荷が高く
て即座に応答できない場合には、そうした問合せ自体に
かなり時間がかかってしまうことがある。そのためネッ
トワークファイルシステムによっては、このようなファ
イルキャッシュのシステムを採用していない場合もあ
る。すなわちこうしたシステムでは、サーバ計算機の保
持するファイルオブジェクトが更新されているにもかか
わらず、ゲートウェイ計算機の持つキャッシュ内の対応
するファイルオブジェクトは必ずしも更新されていな
い。このようなネットワークファイルシステム方式の代
表的なものとして、いわゆるインターネットにおけるＨ
ＴＴＰ（HyperText Transfer Protocol ）を使った広域
分散型マルチメディア情報システムがある。

【００２０】インターネットは、その基本プロトコルと
してＴＣＰ／ＩＰプロトコルを利用した、グローバルな
ネットワークである。インターネット上に構築された地
域分散型マルチメディア情報提供システムは、World Wi
de Web（WWW ）と呼ばれる。ＷＷＷは、ネットワーク上
に分散したファイルオブジェクトを扱うことができる。
これらのファイルオブジェクトは、単なるテキストデー
タにとどまらず、画像データ、音声データ、ビデオ画像
データなどさまざまな種類のものを含む。ＷＷＷは、情
報提供側にとっても、情報利用者（ユーザ）にとっても
魅力的であるため、ネットワーク上のＷＷＷに関するト
ラフィックが爆発的に増加している。ＷＷＷシステムで
は、クライアント計算機のユーザは、グラフィカルユー
ザインタフェースを持ったブラウザソフトウェアをクラ
イアント計算機上で実行させるだけで、ネットワーク上
に分散したサーバ計算機の保持するさまざまなファイル
オブジェクトで構成された情報を次々とアクセスするこ
とができる。ＷＷＷは、このような操作の簡単さのため
に近時めざましい普及を見せている。

【００２１】そしてこのＷＷＷシステムは、ＴＣＰ／Ｉ
Ｐプロトコルの上に構築されたＨＴＴＰプロトコルでフ
ァイルオブジェクトを転送している。

【００２２】ＨＴＴＰプロトコルを実施する上において
は、特開平４−３１３１２６号公報に記載されたような
ゲートウェイ計算機によりファイルオブジェクトを中継
転送することが広く行なわれている。データはゲートウ
ェイ装置にキャッシュされる。またＷＷＷシステムで
は、ファイルオブジェクトの中継転送においてステール
データが発生することは容認されている。すなわちゲー
トウェイ計算機にキャッシュされている内容が、サーバ
計算機の当該ファイルオブジェクトと一致していない場
合を許容している。

【００２３】キャッシュファイル内のステールデータの
率をステールデータ率と呼ぶこととする。何らかの方式
でキャッシュファイルの内容を更新しない限り、ステー
ルデータ率は増加する。一般にキャッシュファイルのス
テールデータ率が増加すると、クライアント計算機を操
作しているユーザは、内容が古いと自主的に判断して、
ファイルオブジェクトをサーバ計算機から再度ロードす
ることを試みる。この場合、キャッシュファイルの内容
を利用しないプロトコルが用いられる。この結果、ゲー
トウェイ計算機内のキャッシュファイルシステムが意味
を持たなくなる傾向がある。

【００２４】一方でこのようにステールデータの発生を
容認するプロトコルの利点もある。クライアント計算機
がサーバ計算機のファイルオブジェクトのアクセスをゲ
ートウェイ計算機に中継依頼してアクセスを行なった場
合、ゲートウェイ計算機のキャッシュファイルにヒット
した場合には、キャッシュファイルからファイルオブジ
ェクトが読出されてクライアントに転送される。サーバ
装置に対する当該ファイルオブジェクトの変更時刻の問
合せは不要である。そのため短時間にファイルオブジェ
クトがキャッシュから取出され、クライアントに返送さ
れる。

【００２５】ＨＴＴＰプロトコルのようにステールデー
タを容認するネットワークファイルプロトコルは、全地
球的な広域ネットワークで利用する上で有利な点を有し
ている。すなわち、ゲートウェイ装置のキャッシュに当
該ファイルオブジェクトがキャッシュされていれば、サ
ーバ装置に対するアクセスが発生しない。その結果応答
時間の短縮を図ることができるという有利な点を持って
いる。

【００２６】上述のようにネットワーク上のファイルオ
ブジェクトのアクセスを高速化し、かつインターネット
のトラフィックを低減させるゲートウェイ計算機は特に
「proxy サーバ装置」とも呼ばれている。

【００２７】「proxy 」とは「代理人」という意味であ
る。proxy サーバ装置はその名のとおり、クライアント
計算機がネットワーク上のサーバ計算機のファイルオブ
ジェクトにアクセスする場合に、そのアクセス要求をサ
ーバ計算機を代理して受付け、ファイルオブジェクトの
転送を中継する機能を果たす。proxy サーバ装置の概念
を図１３を参照して説明する。

【００２８】図１３を参照して、proxy サーバ装置１３
は、たとえばある企業内に設けられた内部ネットワーク
２３と、その企業外の外部ネットワーク（インターネッ
トなど）２５との間に介在して設けられるものである。
内部ネットワーク２３は複数個のクライアント計算機２
４を含み、外部ネットワーク２５は、同じく複数個のサ
ーバ計算機１１を含んでいる。各サーバ計算機１１は、
ファイルオブジェクト１２を保有している。

【００２９】proxy サーバ装置１３は、キャッシュファ
イル１６と、クライアント計算機からリード要求１９を
受け、キャッシュファイル１６内に当該ファイルオブジ
ェクトが存在する場合にはそのファイルオブジェクトを
データ２０として返送し、キャッシュファイル１６内に
当該ファイルオブジェクトの有効なものが存在しない場
合には外部ネットワーク２５を介してサーバ計算機１１
に対するリード要求１７を発行し、対応するファイルオ
ブジェクトをデータ１８として受けてクライアント計算
機２４に対して返送するproxy プロセス１４と、proxy
プロセス１４によるファイルオブジェクトの転送記録を
記録するアクセスログ１５とを含む。proxy プロセス１
４は、サーバ計算機１１からファイルオブジェクトを取
得したときには、当該ファイルオブジェクトをキャッシ
ュファイル１６にも新たに書込む機能を有している。

【００３０】このproxy サーバ装置１３は次のように動
作する。まず、内部ネットワーク２３内のクライアント
計算機２４が、外部ネットワーク２５上のサーバ計算機
１１のファイルオブジェクト１２に対するリード要求１
９をproxy サーバ装置１３内のproxy プロセス１４に対
して発行する。proxy プロセス１４はこのリード要求１
９に応答して、キャッシュファイル１６をアクセスし、
キャッシュファイル中に当該ファイルオブジェクトのキ
ャッシュデータがあるか否かを判定する。当該ファイル
オブジェクトがキャッシュされていれば、proxy サーバ
装置１３固有のキャッシュファイル有効期限と、キャッ
シュされたファイルオブジェクトの最終変更時刻とを比
較する。キャッシュが有効期限内であれば、キャッシュ
ファイルからファイルオブジェクトを読出し（２２）、
そのデータ２０を内部ネットワーク２３の、リード要求
１９を発行したクライアント計算機２４に対して返送す
る。

【００３１】キャッシュファイル内に当該ファイルオブ
ジェクトが存在しない場合、および存在していたとして
も有効期限が過ぎている場合には、キャッシュファイル
１６内に有効なファイルオブジェクトが存在しないもの
と判定される。その場合proxy プロセス１４は、外部ネ
ットワーク２５のサーバ計算機１１に対して、ファイル
オブジェクト１２の読出要求１７を発行する。これに応
答してサーバ計算機１１は、ファイルオブジェクト１２
をデータ１８としてproxy プロセス１４に返送する。pr
oxy プロセス１４は、ログファイル１５に、アクセスロ
グとして、ファイルオブジェクト名称（すなわちネット
ワークプロトコル名称と、サーバ計算機のネットワーク
アドレス名称と、ファイル名称との組）と、ファイルオ
ブジェクトのデータの実体（すなわちファイルオブジェ
クトそのもの）と、書込時刻とを書出す（２６）。

【００３２】proxy プロセス１４はさらに、内部ネット
ワーク２３内のクライアント計算機２４にデータ２０を
転送し、かつキャッシュファイル１６に、当該ファイル
オブジェクトを書込む（２１）。

【００３３】したがってキャッシュファイル１６内に
は、ファイルオブジェクト名称と、ファイルオブジェク
トの実体と、ファイルオブジェクトをサーバ装置から取
得した時刻（最終変更時刻）とが記録されている。

【００３４】proxy サーバは、ＨＴＴＰＤや、 DeleGat
e などのソフトウェアを、ネットワーク接続された、UN
IXの動くコンピュータ上で実行することにより実現され
ることが一般的である。

【００３５】proxy サーバ装置の物理構成を図１４に示
す。図１４を参照してproxy サーバ装置は、UNIXの動作
するワークステーション２００により構成される。ワー
クステーション２００は、ＣＰＵ（中央処理装置）２０
２と、ＣＰＵ２０２に対して内部バス２０４により接続
されたメモリ２０６と、ファイル用のＩ／Ｏ（入出力）
装置２０８と、ルータ２１０を介して外部ネットワーク
に接続される第１ネットワークＩ／Ｏインタフェース２
１２と、内部ネットワークに接続される第２ネットワー
クＩ／Ｏインタフェース２１４とを含む。Ｉ／Ｏ装置２
０８には、キャッシュファイルの蓄積、アクセスログ、
および各種ワークファイルの記憶場所として使用される
ファイル部２１６が接続されている。

【００３６】このワークステーション２００は、ＣＰＵ
２０２が、上述したＨＴＴＰＤや DeleGate というソフ
トウェアを実行することによりproxy サーバ装置１３を
実現する。

【００３７】図１５に、proxy サーバ装置の他の構成例
を示した。このproxy サーバ装置はワークステーション
３００からなっている。ワークステーション３００は、
概略図１４のワークステーション２００と同様の構成で
あるが、図１４の第２ネットワークＩ／Ｏインタフェー
ス２１４に代えて、モデム装置３０４に接続されるシリ
アルポート３０２を有している点が異なっている。そし
てこのワークステーション３００は、モデム装置３０４
および公衆電話回線網３０６を介して内部ネットワーク
と接続されている。

【００３８】図１５において、図１４と同一の部品には
同一の参照番号を与えている。それらの名称および機能
も同一である。したがってここではそれらについての詳
しい説明は繰り返さない。

【００３９】図１６にproxy サーバ装置のさらに他の構
成例を示す。図１６のproxy サーバ装置も、同じくワー
クステーション４００により実現される。このワークス
テーション４００は、概略図１４に示されるワークステ
ーション２００と同様の構成であるが、第１ネットワー
クＩ／Ｏインタフェース２１２および第２ネットワーク
Ｉ／Ｏインタフェース２１４に代えて、内部ネットワー
ク２３に接続された１つのネットワークＩ／Ｏインタフ
ェース４０２を有している点で異なっている。内部ネッ
トワーク２３はルータ２１０を介して外部ネットワーク
２５に接続されており、また複数個のクライアント計算
機２４にも接続されている。ワークステーション４００
は、内部ネットワーク２３およびルータ２１０を介して
外部ネットワーク２５のサーバ計算機１１と通信すると
ともに、内部ネットワーク２３およびクライアント計算
機２４を介してユーザ３１と通信することができる。

【００４０】図１６と図１４とにおいて、同一の部品に
は同一の参照符号および名称を与えている。それらの機
能も同一である。したがってここではそれらについての
詳しい説明は繰り返さない。

【００４１】proxy サーバ装置は、既に述べたように中
継データのキャッシュ機構を有する。すなわち、proxy
サーバ装置は、その内部に存在するキャッシュファイル
装置に、中継するファイルオブジェクトのデータをキャ
ッシュする。

【００４２】proxy サーバ装置のキャッシュファイルに
は、proxy サーバ装置固有の有効期限が定められてい
る。ファイルオブジェクトがキャッシュに書込まれてか
ら有効期限内に、同じサーバ計算機上のファイルオブジ
ェクトへのアクセス要求をクライアント計算機から受取
った場合には、キャッシュファイルに以前に書込まれた
ファイルオブジェクトを取出してクライアント計算機に
転送する。これによりサーバ計算機に対するアクセスは
発生しない。

【００４３】このようなゲートウェイ装置によるキャッ
シュの効果を以下具体的に説明する。proxy サーバ装置
をある会社組織に設置し、外部のネットワークとは６４
ｋｂｐｓの速度で接続するものとする。またこのproxy
サーバは一方で、１０Ｍｂｐｓの速度の会社組織内部の
ローカルエリアネットワークに接続されるものとする。
外部と内部のネットワークの速度差は１桁以上ある。こ
のような例はよく見られる例であり、その典型的な例が
図１６に示す構成である。

【００４４】このとき、proxy サーバで中継ファイルオ
ブジェクトをキャッシュするものとして、キャッシュの
ヒット率を Hitrateとする。 Hitrateは、ファイルオブ
ジェクトに対するアクセス要求に対してキャッシュが１
００％ヒットするとき１であり、０％ヒットするとき０
になる指数である。

【００４５】なおproxy サーバ装置におけるキャッシュ
ファイルからのデータ読出およびキャッシュファイルへ
のデータ書込速度は、ネットワーク速度に比べて十分高
速であるものとする。すなわちキャッシュファイルに対
するファイルオブジェクトの入出力に要する時間は無視
できるものとする。

【００４６】このとき、外部ネットワークにあるファイ
ルオブジェクトを内部からアクセスするときの平均アク
セス速度Ｖａｖｅは次の数１によって表わされる。

【００４７】

【数１】

【００４８】キャッシュファイルが存在しない場合、 H
itrateは０である。したがって平均速度（ｋｂｐｓ）
は、数１から外部ネットワークのアクセス速度６４ｋｂ
ｐｓと等しくなる。また Hitrateが１であれば、すなわ
ち１００％キャッシュファイルにヒットするのであれ
ば、平均速度（ｋｂｐｓ）は、内部ネットワークの速度
と等しく１０，０００ｋｂｐｓ（＝１０Ｍｂｐｓ）とな
る。つまりヒット率が高いほどクライアント計算機から
見た平均アクセス速度は高くなる。ヒット率と平均アク
セス速度との関係を示す数１をグラフ化したものを図１
７に示す。

【００４９】ところで、キャッシュヒット率は、キャッ
シュファイルの量に依存している。すなわちファイルオ
ブジェクトをなるべくたくさんキャッシュファイルの中
に蓄積しておけば、再びアクセスされたファイルオブジ
ェクトがキャッシュファイル中に含まれる確率が高くヒ
ット率が高まる。そうした関係を示すものとして、キャ
ッシュヒット率と、キャッシュファイルの蓄積量との関
係を図１８にグラフとして示す。図１８に示すように、
キャッシュファイルサイズが小さければキャッシュヒッ
ト率は０に近く、キャッシュファイルサイズを大きくす
ればキャッシュヒット率は徐々に上昇する。

【００５０】proxy プロセスにおいては、キャッシュフ
ァイルの内容を維持する方式として、最初のファイルア
クセスによる書込が起きてから一定期間経過したファイ
ルオブジェクトを無効としていく制御方式がとられてい
る。この一定期間を有効期限と呼んでいる。この有効期
限は、proxy サーバ装置を管理する者が実情に合わせて
適切な値を設定する。有効期限を長くとれば、キャッシ
ュファイルに蓄積されるデータ量は増加する。その結果
キャッシュのヒット率は高くなる。すなわちキャッシュ
のヒット率を上げるにはキャッシュの有効期限を長くと
ればよい。

【００５１】なお、キャッシュファイルを格納するファ
イル装置の記憶容量は有限であるから、有効期限を無制
限に長くするわけにはいかない。有効期限が過ぎたキャ
ッシュファイルは、何らかのタイミングで消去される。
このようにキャッシュファイルを消去するまでの時間
を、この明細書では消去時間と呼ぶこととする。

【００５２】本願発明者の実験によれば、キャッシュ有
効期限とキャッシュファイルに蓄積されるファイル量と
はほぼ比例する。この関係を図１９に示す。これは、内
部ネットワークから外部ネットワークへのアクセス量
が、日によらずほぼ一定であるためである。したがって
次のような関係が成り立つ。

【００５３】

【数２】

【００５４】この関係から、図１７に示したように、キ
ャッシュ有効期限を増やすとキャッシュのヒット率が高
まることがわかる。

【００５５】キャッシュ有効期限とファイルオブジェク
トの量との関係は、クライアント計算機を利用する内部
ユーザが、外部ネットワーク上のサーバ計算機のファイ
ルオブジェクトをアクセスする頻度によって異なる。キ
ャッシュ有効期限とキャッシュファイル蓄積量とは、ほ
ぼ比例するものの、その比例係数はネットワーク速度、
内部クライアント計算機ユーザ数などの使用環境により
変動する。

【００５６】なお、本願発明者の関係するシステムで
は、キャッシュファイルが１日程度の有効期限では、キ
ャッシュヒット率は１２％程度である。有効期限を１４
日にするとキャッシュヒット率は４１％程度になること
が経験されている。有効期限１４日のときにはファイル
オブジェクトが７００ＭＢ程度キャッシュファイルに蓄
積されていることが観察されている。

【００５７】

【発明が解決しようとする課題】proxy サーバ装置にお
けるキャッシュファイルにおいては、キャッシュヒット
率をできるだけ高めるためには有効期限をできるだけ長
くとり、キャッシュファイルの容量が許す限りデータを
蓄積することが有効である。しかし一方で、外部ネット
ワーク上のサーバ計算機のファイルオブジェクトの内容
は、修正変更されることがあり得る。キャッシュファイ
ルの有効期限が長いと、その期間中は、サーバ計算機の
ファイルオブジェクトが内容変更されているにもかかわ
らず、内部ネットワークのクライアント計算機のユーザ
は、キャッシュファイルに蓄積された古い内容を読出す
ことになってしまうことになる。

【００５８】たとえば天気図や電子新聞などのファイル
オブジェクトをサーバ計算機上で提供する場合を考え
る。こうしたファイルオブジェクトは、同一名称であり
ながらそのデータの性格上毎日情報更新されるものが多
い。たとえばキャッシュ有効期限が７日である場合を考
えると、キャッシュにある天気図や電子新聞等の情報
は、６／７以上の確率で古いものとなり、結局役に立た
ない情報となってしまう。

【００５９】このようにキャッシュファイルの内容のう
ち、外部ネットワークに存在する元のデータが変更さ
れ、キャッシュの内容と一致していない割合をステール
データ率と呼ぶ。すなわちキャッシュ有効期限を増やせ
ば、キャッシュ蓄積サイズが増加し、キャッシュヒット
率は増加するが、有効期限が長くなった結果、キャッシ
ュ内容のステールデータ率も増加してしまう。

【００６０】したがって従来技術においては、キャッシ
ュファイルの中のファイルオブジェクトの内容の新鮮さ
を保つことと、キャッシュヒット率を高く維持すること
とは、互いに相反する目標である。

【００６１】既に述べたように一般にキャッシュファイ
ルのステールデータ率が増加すると、クライアント計算
機のユーザは、内容が古いはずであると自主的に判断
し、ファイルオブジェクトデータをサーバ計算機から再
度ロードするようになる。これには、キャッシュファイ
ルを参照せず、実際にサーバ計算機からロードすること
を指定するプロトコルが利用される。この結果、キャッ
シュが意味を持たなくなる傾向がある。

【００６２】このようなステールデータ率の増加は望ま
しいことではなく、そのためキャッシュの有効期限はあ
まり長くとることはできない。通常は２４時間以下であ
る。しかし有効期限をこの程度とした場合には、キャッ
シュファイルにファイルオブジェクトが十分に蓄積され
ず、キャッシュのヒット率は高まらない。その結果平均
ファイルオブジェクト転送速度を十分上げることができ
ないという問題点があった。また、キャッシュのヒット
率を高めるにあたって、他の通常プロセスに対して与え
る悪影響はできるだけ低くした方が好ましい。さらに、
通常の他のプロセスが多数あった場合にも、キャッシュ
のヒット率を向上させるための作業が常にできるのが好
ましく、またそのための作業自体できるだけ効率良く行
なうことが望ましい。

【００６３】それゆえに請求項１に記載の発明の目的
は、キャッシュファイルの内容を新鮮に保つとともに、
キャッシュヒット率も向上させることである。

【００６４】請求項２から６記載の発明の目的は、キャ
ッシュファイルの内容を新鮮に保つとともに、キャッシ
ュヒット率も向上させるようにし、さらにプリフェッチ
に要する時間を短縮することである。

【００６５】請求項７または８記載の発明の目的は、通
常のユーザの利用に悪影響を与えることなく、キャッシ
ュファイルの内容を新鮮に保つとともに、キャッシュヒ
ット率も向上させるようにすることである。

【００６６】請求項９記載の発明の目的は、常にキャッ
シュファイルの内容を新鮮に保つとともに、キャッシュ
ヒット率も向上させるようにすることである。

【００６７】請求項１０記載の発明の目的は、無駄なト
ラフィックを発生させることなく、キャッシュファイル
の内容を新鮮に保つとともに、キャッシュヒット率も向
上させるようにすることである。

【００６８】請求項１１記載の発明の目的は、通常のユ
ーザの利用に与える悪影響を最小限に抑えつつ、キャッ
シュファイルの内容を新鮮に保ちかつキャッシュヒット
率をも向上させるための作業を着実に行なえるゲートウ
ェイ装置を提供することである。

【００６９】請求項１２から１６に記載の発明の目的
は、キャッシュファイルの内容を新鮮に保つことと、キ
ャッシュヒット率を向上させることとを、ともに、かつ
効率的に達成することができるゲートウェイ装置を提供
することである。

【００７０】

【課題を解決するための手段】請求項１に記載の発明
は、クライアント計算機が存在する第１のネットワーク
と、サーバ計算機が存在する第２のネットワークとの間
に介在するように設けられるゲートウェイ装置であっ
て、第１のネットワークのクライアント計算機からのフ
ァイルオブジェクトに対するアクセス要求に応答して、
当該ファイルオブジェクトにより指定されるサーバ計算
機に対して、当該ファイルオブジェクトに対するアクセ
ス要求を行なう第１のネットワークファイル中継手段を
含む。第１のネットワークファイル中継手段は、取得し
たファイルオブジェクトを、所定の有効期限が経過する
まで一時的に蓄積するとともに、最終変更時刻をファイ
ルオブジェクト単位で記録するためのキャッシュファイ
ル手段と、過去の、一定期間内に行なわれたファイルオ
ブジェクトの転送記録を蓄積するファイル転送記録手段
と、ファイルオブジェクトに対するアクセス要求に応答
して、最終変更時刻を参照し、有効期限内のファイルオ
ブジェクトがキャッシュファイル手段に存在するか否か
を判断し、当該判断結果に基づいてキャッシュファイル
手段または当該ファイルオブジェクトにより指定される
サーバ計算機を選択的にアクセスして当該ファイルオブ
ジェクトを取得してクライアント計算機に転送するため
の転送手段とを含む。ゲートウェイ装置はさらに、予め
定められたスケジュールに従って、転送記録中のファイ
ルオブジェクトをサーバ計算機からプリフェッチして、
キャッシュファイル手段に格納するための第２のネット
ワークファイル中継手段を含む。

【００７１】一定期間内に転送が行なわれたファイルオ
ブジェクトは、第２のネットワークファイル中継手段に
よって、予め定められるスケジュールに従って、アクセ
ス要求がなくてもプリフェッチされる。有効期限内のも
のはもちろん、有効期限が切れたものもプリフェッチさ
れキャッシュファイル手段に新たに格納され有効とな
る。実際にアクセス要求があったときに、当該ファイル
オブジェクトであって有効期限内のものがキャッシュフ
ァイルに存在している可能性が高くなる。また有効期限
を長くしても、プリフェッチ時に最新のものに更新され
るので、キャッシュファイル手段内のファイルオブジェ
クトを、高い確率でサーバ計算機のファイルオブジェク
トと一致させることができる。そのため、キャッシュフ
ァイルの内容を新鮮に保つとともに、キャッシュヒット
率も向上させることが可能である。

【００７２】請求項２記載のゲートウェイ装置は、請求
項１記載のゲートウェイ装置であって、第２のネットワ
ークファイル中継手段は、第２のネットワークを介して
同時に複数個のファイルオブジェクトをサーバ計算機か
ら同時並列的にプリフェッチする。

【００７３】同時並列的にプリフェッチが行なわれるの
で、順次行なう場合と比較してプリフェッチに要する時
間を短縮することができる。

【００７４】請求項３記載のゲートウェイ装置は、請求
項２記載のゲートウェイ装置であって、第２のネットワ
ークファイル中継手段は、同一のサーバ計算機からのプ
リフェッチの同時発生を回避するように、ファイルオブ
ジェクトのプリフェッチの順序を決定する。

【００７５】転送記録では、同一のサーバ計算機に対す
るアクセス要求が集中して発生することが多い。同一の
サーバ計算機に対して一度にプリフェッチのためのアク
セス要求が集中すると、サーバ計算機に負荷がかかる上
に、通信路にも負荷がかかるため、ファイルオブジェク
トの転送に時間がかかる。そこで同一のサーバ計算機か
らのプリフェッチの同時発生を回避するようにプリフェ
ッチの順序を決定することで、そうした特定のサーバ計
算機に負荷が集中することがなくなり、プリフェッチの
速度を向上させることができる。

【００７６】請求項４記載のゲートウェイ装置は、請求
項２記載のゲートウェイ装置であって、第２のネットワ
ークファイル中継手段は、転送記録からファイルオブジ
ェクトのリストを当該転送記録中の出現頻度に従って抽
出し、当該リスト中のファイルオブジェクトの順序に従
ってファイルオブジェクトのプリフェッチを同時並列的
に行なう。

【００７７】ファイルオブジェクトのプリフェッチにあ
たって、転送記録中の出現頻度の高いファイルオブジェ
クトが優先的にプリフェッチされる。そうしたファイル
オブジェクトに対するアクセス要求は将来も高い割合を
示すと考えられるので、キャッシュヒット率の向上が期
待できる。

【００７８】請求項５記載のゲートウェイ装置は、請求
項４記載のゲートウェイ装置であって、第２のネットワ
ークファイル中継手段は、リスト中のファイルオブジェ
クトの順序を入替え、当該入替られた順序に従ってファ
イルオブジェクトのプリフェッチを同時並列的に行な
う。

【００７９】転送記録中には、同一のサーバ計算機に対
するアクセス要求が集中して発生することが多い。同一
のサーバ計算機に対して一度にプリフェッチのためのア
クセスが集中すると、サーバ計算機に負荷がかかる上
に、通信路上でも負荷がかかるため、ファイルオブジェ
クトの転送に時間がかかる。転送記録から抽出されたフ
ァイルオブジェクトのリスト中のファイルオブジェクト
の順番を入替え、その順序でプリフェッチをすること
で、同一のサーバ計算機からのプリフェッチの同時発生
を回避できるようになる。したがって特定のサーバ計算
機に負荷が集中することがなくなり、プリフェッチの速
度を向上させることができる。

【００８０】請求項６記載のゲートウェイ装置は、請求
項５記載のゲートウェイ装置であって、第２のネットワ
ークファイル中継手段は、リストを複数個のブロックに
区分し、各ブロックごとにファイルオブジェクトの順序
を入替え、当該順序が入替えられたリスト上での順序に
従ってファイルオブジェクトのプリフェッチを同時並列
的に行なう。

【００８１】このような入替を行なうと、同一のサーバ
計算機へのアクセス要求の集中的な発生が回避される上
に、ファイルオブジェクトのリスト中の出現頻度順序
は、ブロックのサイズの粒度で保たれる。したがって、
リスト中の出現頻度の高いファイルオブジェクトのプリ
フェッチが、特定のサーバ計算機へのアクセス要求の集
中的な発生を招くことなく行なえる。

【００８２】請求項７記載のゲートウェイ装置は、請求
項２から６のいずれかに記載のゲートウェイ装置であっ
て、第１のネットワークファイル中継手段は、各々が第
１のネットワークのクライアント計算機からのファイル
オブジェクトのアクセス要求を処理するための第１の転
送プロセスを複数個、同時並列的に起動させることが可
能である。第２のネットワークファイル中継手段は、各
々が１つのファイルオブジェクトのプリフェッチを行な
うための第２の転送プロセスを複数個、同時並列的に起
動させることが可能であり、かつ第１の転送プロセスの
数を検知して、第１の転送プロセスの数と、第２の転送
プロセスの数との和が予め定められる上限以下となるよ
うに第２の転送プロセスの新たな起動を制御する。

【００８３】第１のプロセスが多数発生しているときは
第２のプロセスの起動を抑制し、第１のプロセスが僅か
しか発生していないときには第２のプロセスを多数起動
させることができるので、通常のユーザによるファイル
オブジェクトのアクセス要求が、プリフェッチのために
悪影響を受けることがない。また通常のユーザによるア
クセス要求の少ないときには随時プリフェッチを行なえ
るので、キャッシュの新鮮さを保つことができる。

【００８４】請求項８記載のゲートウェイ装置は、請求
項１から７のいずれかに記載のゲートウェイ装置であっ
て、第２のネットワークファイル中継手段は、予め定め
られた時間帯でのみファイルオブジェクトのプリフェッ
チを行なう。

【００８５】ユーザによるアクセス要求が非常に少ない
時間帯にプリフェッチを行なってキャッシュファイルの
新鮮さを保つことができるとともに、ユーザによるアク
セス要求が発生する時間帯になるとプリフェッチを行な
わないようにでき、通常のユーザによるファイルオブジ
ェクトのアクセス要求が、プリフェッチのために悪影響
を受けることがない。

【００８６】請求項９記載のゲートウェイ装置は、請求
項１から８のいずれかに記載のゲートウェイ装置であっ
て、第２のネットワークファイル中継手段は、第１のネ
ットワークファイル中継手段のキャッシュファイルの有
効期限以下の周期で定期的にファイルオブジェクトのプ
リフェッチを行なう。

【００８７】キャッシュファイルの有効期限以下の周期
で定期的にキャッシュファイルのファイルオブジェクト
のプリフェッチが行なわれるので、キャッシュファイル
中のファイルオブジェクトは常に有効期限内に保たれ
る。その結果、プリフェッチとプリフェッチとの間の全
期間にわたりプリフェッチの効果を保つことができる。

【００８８】請求項１０記載のゲートウェイ装置は、請
求項１に記載のゲートウェイ装置であって、第１のネッ
トワークファイル中継手段のキャッシュファイル手段
は、有効期限以上の所定の消去時間が経過するまでは、
当該キャッシュファイル手段に格納されているファイル
オブジェクトを消去しない。転送手段は、有効期限が経
過しているが消去はされていないファイルオブジェクト
に対するアクセス要求に応答して、対応するサーバ計算
機にアクセスし、当該サーバ計算機内の当該ファイルオ
ブジェクトが、前回の取得後更新されているか否かを判
断する。そして更新されていないときにはキャッシュフ
ァイル手段内のファイルオブジェクトを新たに取得した
ファイルオブジェクトとしてクライアント計算機に転送
する。更新されているときには当該ファイルオブジェク
トにより特定されるサーバ計算機に対して当該ファイル
オブジェクトの転送要求を発して更新後の当該ファイル
オブジェクトを取得し、取得したファイルオブジェクト
をクライアント計算機に転送する。

【００８９】有効期限が経過しているファイルオブジェ
クトであっても、消去時間前であれば消去されない。こ
うしたファイルオブジェクトについてのアクセス要求が
発生したときに、有効期限が切れていても、サーバ計算
機において更新されていないファイルオブジェクトは、
直接サーバ計算機から取得することなく、キャッシュフ
ァイルから得ることができる。したがって無駄なトラフ
ィックの発生を抑制できる。その上、そうしたアクセス
要求があって、かつサーバ計算機において当該ファイル
オブジェクトが更新されていなかった場合には、実際に
ファイルオブジェクトをサーバ計算機から改めて取得す
ることなくプリフェッチと同じ効果を得ることができ
る。

【００９０】請求項１１記載の発明に係るゲートウェイ
装置は、請求項２から６のいずれかに記載のゲートウェ
イ装置であって、第１のネットワークファイル中継手段
は、各々が第１のネットワークのクライアント計算機か
らのファイルオブジェクトのアクセス要求を処理するた
めの第１の転送プロセスを複数個、同時並列的に起動さ
せることが可能である。第２のネットワークファイル中
継手段は、各々が１つのファイルオブジェクトのプリフ
ェッチを行なうための第２の転送プロセスを複数個、同
時並列的に起動させることが可能である。第２のネット
ワークファイル中継手段は、第２の転送プロセスの起動
時において、既に稼動中の転送プロセスの数を検知し
て、稼動中の転送プロセスの数と、起動すべき第２の転
送プロセスの数との和が、稼動中の転送プロセスの数と
予め定められる定数との和以下となるように第２の転送
プロセスの新たな起動を制御する。

【００９１】第１のプロセスが多数発生しているときは
第２のプロセスの起動を抑制し、第１のプロセスが僅か
しが発生しないときには第２のプロセスを多数起動させ
ることができるので、通常のユーザによるファイルオブ
ジェクトのアクセス要求が、プリフェッチのために悪影
響を受けることがない。また通常のユーザによる要求の
少ないときには随時プリフェッチを行なえるので、キャ
ッシュの新鮮さを保つことができる。また、稼動中の転
送プロセスの数が上限に達していても、予め定められる
定数個までの第２の転送プロセスを起動することができ
るので、プリフェッチを着実に行なうことができる。そ
のため、キャッシュの新鮮さを保つことができる。また
キャッシュファイル手段の容量を小さくする必要はない
ので、キャッシュヒット率も向上する。

【００９２】請求項１２に記載の発明に係るゲートウェ
イ装置は、請求項１記載のゲートウェイ装置であって、
第２のネットワークファイル中継手段は、過去の一定期
間内に行なったファイルオブジェクトの転送記録を、当
該ファイルオブジェクトの変更が検出されたか否かを示
す情報とともに蓄積するための第２のファイル転送記録
手段をさらに含む。第２のネットワークファイル中継手
段は、第２のファイル転送記録手段によりファイルオブ
ジェクトのプリフェッチ時に記録された転送記録中か
ら、直前のプリフェッチ時において変更が検出されたフ
ァイルオブジェクトを抽出し、これらのファイルオブジ
ェクトを、ファイル転送記録手段の転送記録中のファイ
ルオブジェクトよりも優先的にサーバ計算機からプリフ
ェッチしてキャッシュファイル手段に格納する。

【００９３】前回のフェッチ時に変更が検出されたファ
イルオブジェクトが、それ以外のファイルオブジェクト
よりも優先してプリフェッチされる。こうしたファイル
オブジェクトは、以後も変更される頻度が高いと考えら
れる。そのため、請求項１に記載の発明の効果に加え
て、キャッシュファイルの内容を新鮮に保つ上で、前回
のフェッチ時以降に変更があった可能性の高いファイル
オブジェクトが優先的にプリフェッチされるので、プリ
フェッチを効率的に行なうことができる。

【００９４】請求項１３に記載の発明に係るゲートウェ
イ装置は、請求項１２記載のゲートウェイ装置であっ
て、第２のネットワークファイル中継手段は、予め指定
された文字列パターンを記憶し、第２のファイル転送記
録手段により記録された転送記録中から、この予め定め
られた文字列パターンと一致する文字列を有するファイ
ルオブジェクトを排除して抽出する。

【００９５】ファイルオブジェクトの中には、プリフェ
ッチすることが無意味であったり、プリフェッチしてお
くためにかえってシステム全体の効率が低下してしまう
ようなファイルオブジェクトも存在する。そうしたファ
イルオブジェクトの中には、特定の文字列を含んでいる
ものとして予め知ることができるものがある。そこでこ
のような特定の文字列を予め指定し文字列パターンとし
て第２のネットワークファイル中継手段に記憶させてお
き、この文字列パターンと一致する文字列を有するファ
イルオブジェクトを排除して抽出し、残りのファイルオ
ブジェクトのみプリフェッチする。

【００９６】こうすることで、プリフェッチにより、よ
り有用なデータをより多くキャッシュファイル手段にプ
リフェッチすることができるので、請求項１２に記載の
発明の効果に加えて、キャッシュファイルの内容を新鮮
に保つことと、キャッシュヒット率を向上させることと
を、効率的に達成することができる。

【００９７】請求項１４に記載の発明に係るゲートウェ
イ装置は、請求項１２の記載の発明の構成に加えて、第
２のファイル転送記録手段の蓄積する転送記録は、取得
されたファイルオブジェクトのファイルサイズをさらに
含む。第２のネットワークファイル中継手段は、転送対
象となるファイルオブジェクトサイズの最大値を特定す
る情報を予め記憶し、第２のファイル転送記録手段によ
り記録された転送記録中から、記憶された最大値より大
きなファイルサイズを有するファイルオブジェクトを排
除して抽出する。

【００９８】大きなデータサイズのファイルオブジェク
トは、プリフェッチに時間がかかる。通常プリフェッチ
の処理は、ユーザの少ない限られた時間帯に行なわれる
ことが多い。この限られた時間帯内に、できるだけ多く
の数のファイルオブジェクトのプリフェッチを完了させ
ようとすれば、大きなファイルオブジェクトのプリフェ
ッチは避けることが望ましい。場合によっては有限のプ
リフェッチ時間内に、多大なサイズのファイルオブジェ
クトのプリフェッチが完了せず、結果としてプリフェッ
チが全く行なわれないことさえあり得る。そのため、デ
ータサイズの大きなファイルオブジェクトのプリフェッ
チを回避することにより、有限のプリフェッチ時間内に
多数のファイルオブジェクトをファイルキャッシュ手段
内にプリフェッチすることができ、キャッシュファイル
手段に格納された有効なデータ量を増やすことができ
る。結果として、キャッシュファイルの内容を新鮮に保
つことと、キャッシュヒット率を向上させることとが、
効率的に行なわれる。

【００９９】請求項１５に記載の発明に係るゲートウェ
イ装置は、請求項１２に記載のゲートウェイ装置であっ
て、第２のファイル転送記録手段の蓄積する転送記録
は、取得が試行されたファイルオブジェクトに関するサ
ーバ計算機の状態コードをさらに含んでいる。第２のネ
ットワークファイル中継手段は、サーバ計算機の特定の
状態コードを予め記憶し、第２のファイル転送記録手段
により記録された転送記録中から、この特定の状態コー
ドと一致する状態コードを有するファイルオブジェクト
を排除して抽出する。

【０１００】サーバ計算機が、たとえばファイル送信の
行なえない異常な状態にある場合、このサーバ計算機に
対してファイルオブジェクトの送信を要求するのは無駄
である。そのような無駄なファイルアクセスを行なわず
に、他の有効なサーバ計算機に対してファイルオブジェ
クトのプリフェッチを行なえば、有限の時間内により多
くの有効なデータをファイルキャッシュ手段内に蓄積す
ることができる。その結果、キャッシュファイルの内容
を新鮮に保ち、かつキャッシュヒット率を向上させるこ
とが効率的に行なえる。

【０１０１】請求項１６に記載の発明に係るゲートウェ
イ装置は、請求項１〜１５のいずれかに記載のゲートウ
ェイ装置であって、第１のネットワークファイル中継手
段に対するクライアント計算機としての機能を実現する
ための手段をさらに含んでいる。

【０１０２】ゲートウェイ装置に、クライアント計算機
としての機能を持たせることにより、プリフェッチした
いファイルに対するアクセス要求をクライアント計算機
としての機能を通じてゲートウェイ装置に出すことがで
きる。そのためプリフェッチされるファイルオブジェク
トの量をさらに増やすことができ、キャッシュファイル
の内容を新鮮に保つことと、キャッシュヒット率を向上
させることとを、ともに、かつ効率的に達成することが
できる。

【０１０３】

【発明の実施の形態】

［実施の形態１］本発明が適用されるゲートウェイ装置
（proxy サーバ装置と呼ぶ）は、ネットワークインタフ
ェースを備えたUNIX OS の稼動する計算機によって、以
下の説明および図面を参照すれば容易に実現可能であ
る。そうしたproxy サーバ装置の構成の一例は図１６に
示したとおりである。図１６のproxy サーバ装置につい
ては既に説明したので、その構成についての詳細な説明
はここでは繰返さない。

【０１０４】通常は、ユーザ３１がクライアント計算機
２４を使用してproxy サーバ装置（図１６におけるprox
y サーバ装置４００）に対して、サーバ計算機１１のフ
ァイルオブジェクト１２を取得するようネットワーク２
３を経由して依頼を出す。ファイルオブジェクト１２
は、前述したようにプロトコル名称と、サーバ計算機の
ネットワークアドレス名称と、ファイルオブジェクトの
名称と、ファイルデータの実体との組からなっている。

【０１０５】図１に、本願発明に係るproxy サーバ装置
の第１の実施の形態に係る装置５３のシステム構成を示
す。図１を参照して、proxy サーバ装置５３は、内部ネ
ットワーク２３および外部ネットワーク２５に接続され
た第１のproxy プロセス１４と、第１のproxy プロセス
１４が使用するキャッシュファイル１６と、第１のprox
y プロセス１４が、アクセスログ（転送記録）としてフ
ァイルオブジェクトの名称を記録するアクセスログ１５
と、第１のproxy プロセス１４の過去のアクセスログ１
０を読出してファイルのアクセスリスト３０を作成する
とともに、このアクセスリスト３０に掲載されたファイ
ルオブジェクトを外部ネットワーク２５のサーバ計算機
１１からプリフェッチするための要求を発生するプリフ
ェッチプロセス３６と、プリフェッチプロセス３６のプ
リフェッチ要求に応答して、外部ネットワーク２５のサ
ーバ１１から該当するファイルオブジェクトを取得し、
キャッシュファイル１６に再格納することによりキャッ
シュファイルの内容を最新のものに保つための第２のpr
oxy プロセス３４とを含む。

【０１０６】第１のproxy プロセス１４と、第２のprox
y プロセス３４と、プリフェッチプロセス３６とはいず
れも、たとえば図１６に示すメモリ２０６内にプログラ
ムとして格納され、ＣＰＵ２００によってこれを実行す
ることにより実現される。

【０１０７】第１のproxy プロセス１４が、特許請求の
範囲に記載の転送手段に相当し、キャッシュファイル１
６がキャッシュファイル手段に相当し、アクセスログ１
５がファイル転送記録手段に相当する。またプリフェッ
チプロセス３６と、アクセスリスト３０と、第２のprox
y プロセス３４とにより第２のネットワークファイル中
継手段が構成される。

【０１０８】第２のproxy プロセス３０は、本願発明に
係るゲートウェイ装置に特有のものであるが、次のよう
な条件に従って起動されている。

【０１０９】（１）第２のproxy プロセス３０は、第
１のproxy プロセス１４と共通のキャッシュファイル１
６を使用する。

【０１１０】（２）第２のproxy プロセス３４のキャ
ッシュ有効期限は０に設定される。すなわち第２のprox
y プロセスを経由するサーバ計算機へのアクセスは、キ
ャッシュミスヒット状態となり必ず外部ネットワーク２
５内のサーバ計算機に対して行なわれ、ファイルオブジ
ェクトを取得してキャッシュファイル１６に格納する。

【０１１１】図１に示すproxy サーバ装置５３の動作に
ついて以下説明する。内部ネットワーク２３内のクライ
アント計算機２４が、このproxy サーバ装置５３に対し
てネットワークアクセス要求１９を与えるものとする。
第１のproxy プロセス１４が、このネットワークアクセ
ス要求１９を受取り、まずＩ／Ｏインタフェース２０２
（図１５、図１６、図１７参照）を経由してファイル装
置２１６内に存在するキャッシュファイル１６をアクセ
スする（２１）。また第１のproxy プロセス１４は、こ
のネットワークアクセス要求とキャッシュファイル１６
内のファイルオブジェクト名称とを比較し（２２）、一
致しているか否かを判定する。一致したものがあれば第
１のproxy プロセス１４はさらに、当該ファイルオブジ
ェクトのキャッシュファイル１６内の最終変更時刻を抽
出し（２２）、現在の時刻と比較する。そして現在の時
刻が、当該ファイルオブジェクトの最終変更時刻を起点
とする有効期限内であれば、キャッシュファイル１６か
ら当該ファイルオブジェクトを抽出し（２２）、ネット
ワークＩ／Ｏインタフェース４０２（図１６参照）を経
由してクライアント計算機２４にファイルオブジェクト
を返す（２０）。

【０１１２】該当するファイルオブジェクトのコピーが
キャッシュファイル１６内に存在していない場合、また
は存在していてもそのキャッシュ有効期限が切れている
場合には第１のproxy プロセス１４は、ネットワークＩ
／Ｏインタフェース４０２（図１６参照）を経由して外
部ネットワーク２５のサーバ計算機１１にファイルオブ
ジェクト転送要求１７を送る。このときのサーバ１１
は、当該ファイルオブジェクト内のネットワークアドレ
ス名称により特定される。

【０１１３】該当するサーバ１１は、要求されたファイ
ルオブジェクトを第１のproxy プロセス１４に返送する
（１８）。すなわちこのファイルオブジェクトが第１の
proxy プロセス１４により取得される。

【０１１４】第１のproxy プロセス１４は、このファイ
ルオブジェクトをキャッシュファイル１６にその最終変
更時刻とともに書込み（２１）、アクセスログ１５にこ
のファイルオブジェクトの名称を記録する（２６）。

【０１１５】一方、本願発明のproxy サーバ装置５３
は、プリフェッチプロセス３６と第２のproxy プロセス
３０とをＣＰＵにより処理走行させてファイルオブジェ
クトのプリフェッチを行なう点において従来のproxy サ
ーバ装置と相違する。

【０１１６】プリフェッチプロセス３６および第２のpr
oxy プロセス３４は次のように動作する。プリフェッチ
プロセス３６は、第１のproxy プロセス１４の過去のア
クセスログ１５を読出し（２７）、ファイル装置内にフ
ァイルアクセスリスト３０を作成する（２８）。プリフ
ェッチプロセス３６はさらに、このアクセスリスト３０
に掲載されたファイルオブジェクトを読出し（２９）、
当該ファイルオブジェクトに対するアクセス要求を第２
のproxy プロセス３４に対して与える（３１）。第２の
proxy プロセス３４は、このアクセス要求を外部ネット
ワーク２５のサーバ１１に対して与え（３２）、当該フ
ァイルオブジェクトを取得する（３３）。取得されたフ
ァイルオブジェクトはキャッシュファイル１６内にその
最終変更時刻とともに書込まれる。すなわちこれにより
キャッシュファイル１６内の当該ファイルオブジェクト
は、クライアント計算機２４からのアクセス要求がなく
とも最新のものに書直される。また前述のとおり第２の
proxy プロセス３４のキャッシュ有効期限は０に設定さ
れているため、プリフェッチプロセス３６からアクセス
要求３１が第２のproxy プロセス３４に渡されると、必
ず当該ファイルオブジェクトに対するアクセス要求が第
２のproxy プロセス３４によって外部ネットワーク２０
に与えられる。

【０１１７】このように第２のproxy プロセス３４を起
動すると、大きく次の２つの効果を得ることができる。

【０１１８】（１）第１のproxy プロセス１４では、
キャッシュファイル１６の有効期限がある値に設定され
ている。この有効期限をＭ時間であるものとする。仮に
プリフェッチプロセス３６が第２のproxy プロセス３４
ではなく第１のproxy プロセス１４に対してファイルオ
ブジェクトのプリフェッチのためのアクセス要求を与え
るものとすると、キャッシュファイル１６にヒットして
しまう確率が高い。これでは、外部ネットワーク２５内
の元のファイルオブジェクトに対するアクセスが行なわ
れず、プリフェッチが有効には行なわれない。

【０１１９】一方前述のように第２のproxy プロセス３
４は、そのキャッシュ有効期限が０に設定されている。
そのため第２のproxy プロセスに対してアクセス要求が
与えられると、必ずキャッシュミスが発生し、外部ネッ
トワーク２５に対するファイルオブジェクトのアクセス
が行なわれる（３２）。そのようにしてサーバから当該
ファイルオブジェクトが取得され（３３）、取得された
ファイルオブジェクトがキャッシュファイル１６に書込
まれる（３５）ことによりキャッシュファイル１６内の
ファイルオブジェクトが最新の状態に維持される。

【０１２０】（２）第１のproxy プロセス１４はアク
セスログ１５を残す。プリフェッチプロセス３６はこの
アクセスログ１５から、プリフェッチすべきファイルオ
ブジェクト名称を抽出したアクセスリスト３０を作成す
る。

【０１２１】仮にプリフェッチプロセス３６が第１のpr
oxy プロセス１４に対して、サーバ計算機内のファイル
オブジェクトのプリフェッチのためのアクセス要求を与
えたとすると、その結果のアクセスログがアクセスログ
１５に記録されてしまう。プリフェッチプロセス３６
は、次回のプリフェッチ動作においてこのアクセスログ
１５をもとにアクセスすべきファイルオブジェクトのリ
スト３０を作成するので、その結果作成されるアクセス
リスト３０には、同一のファイルオブジェクトが多重に
出現してしまうことになる。そうしたアクセスリスト３
０によってプリフェッチを行なった場合、クライアント
計算機２４からのファイルオブジェクトのアクセス要求
の傾向を反映したものとは言えなくなるおそれがある。
第２のproxy プロセス３４を用い、プリフェッチを行な
うことにより、アクセスログ１５にはプリフェッチにら
るアクセスログは書込まれないことになる。そのためア
クセスリスト３０は、クライアント計算機２４からのフ
ァイルオブジェクトのアクセス要求の傾向を正確に反映
したものとなる。

【０１２２】アクセスリスト３０を作成する際には、プ
リフェッチプロセス３６はアクセスログ１５内から、過
去の一定期間（これをｎ日とする）のファイルオブジェ
クト名称を抽出する。ただしｎ×２４（時間）は第１の
proxy プロセス１４のキャッシュ有効期限Ｍ時間よりも
大きい。

【０１２３】既に図１４を参照して説明したように、通
常はキャッシュ有効期限が短ければキャッシュファイル
に蓄積される容量は少なく、大きくなれば大きくなる。
ヒット率はキャッシュファイルに蓄積されたファイルオ
ブジェクトの量が多いほど高くなることは、既に図１３
を参照して説明した。しかしまた、キャッシュファイル
サイズを大きくすればステールデータ率が増加してしま
うことについても既に説明した。

【０１２４】本願発明のゲートウェイ装置では、第１の
proxy プロセス１４のキャッシュ有効期限はＭ時間であ
る。しかしプリフェッチプロセス３６がプリフェッチの
対象とするファイルオブジェクトは、ｎ日（ｎ×２４＞
Ｍ）のアクセスログから抽出されている。したがってプ
リフェッチプロセス３６および第２のproxy プロセス３
４によってキャッシュファイル１６内に蓄積されるファ
イルオブジェクトの量は、ｎ×２４時間分だけある。す
なわち、蓄積されているファイルオブジェクトのデータ
量は十分大きいのでキャッシュのヒット率は高くなる。
一方で第１のproxy プロセス１４のキャッシュ有効期限
はＭ時間に保たれているので、プリフェッチを適切な時
期に行なっておけばステールデータ率が高くなるおそれ
はない。

【０１２５】本発明を非常に有効に適用できる例とし
て、インターネット上のＷＷＷシステムがある。ＷＷＷ
システム上でのproxy サーバ装置において本願発明のプ
リフェッチプロセスを行なう手順を以下に説明する。

【０１２６】ＷＷＷシステムでは、ネットワーク上に分
散したファイルオブジェクト名称はUniform Resource L
ocator（ＵＲＬ）と呼ばれる形式で表現され、特定され
る。ＵＲＬの一例を次に示す。

【０１２７】

【数３】

【０１２８】数３において「http」は使用するプロトコ
ルを示す。「www.xxx.co.jp 」は、ネットワーク上のＨ
ＴＴＰサーバ計算機のアドレスを示すものであり、ネッ
トワーク上で同一のものはないよう選ばれている。また
「/test/index.html」はサーバ計算機内のファイル名称
を示す。

【０１２９】第１のproxy プロセスとして一般に利用さ
れているDeleGateを使用する場合は、そのアクセスログ
の例は次のように、内部ネットワーククライアント計算
機名称と、時刻と、“ＨＴＴＰプロトコル（ファイル取
得要求）”、などとなる。

【０１３０】

【数４】

【０１３１】数４に示すアクセスログは、図２に示すよ
うな、出願人がインターネット上で公開している情報ペ
ージをアクセスした場合のログに相当する。図２に示さ
れるぺージは、テキストと、６個のグラフィックデータ
とから構成されているので、このページに対するアクセ
スを１回行なうと、６個のグラフィックデータに対する
アクセスも含む７つのアクセスログが形成される。すな
わち上述のログにおいて第１行目はこの情報ページのテ
キストに対するアクセス要求であり、残りの６行は表紙
に貼り込まれた出願人の会社のロゴのグラフィックデー
タ（sharpcolor.gif）、出願人会社内の情報システム事
業本部と呼ばれる事業部のロゴ（isg.gif ）と、出願人
会社の４つの製品の写真のグラフィックデータ（Zauru
s.gif, Shoin.gif, Prostation.gif, S2.gif ）の取得
要求を示している。

【０１３２】ＨＴＴＰプロトコルは、コマンド文字列
（ＧＥＴなど）と、ＵＲＬと、プロトコルバージョン
（「HTTP/1.0」など）から構成されている。以下はその
一例である。

【０１３３】

【数５】

【０１３４】ＨＴＴＰプロトコルについては、最後に掲
げる表内に示された参考文献のうち、参考文献３および
参考文献４に記載されている。プリフェッチプロセスの
実施手順について以下に説明するが、そのための前提条
件は次の（１）および（２）となっている。

【０１３５】（１）第１のproxy プロセスは、キャッ
シュ有効期限Ｍ（時間）を、キャッシュログの収集期間
ｎ日より短く設定する。たとえばＭ＝２４時間、ｎ＝７
日とする。

【０１３６】（２）第２のproxy プロセスは、キャ
ッシュファイルを第１のproxy プロセスのものと共有
し、キャッシュ有効期限を０に設定する、という２つ
の条件に従って起動される。

【０１３７】このような条件のもとに、以下に述べる手
順のプリフェッチプロセスを毎日一定時刻に起動する。
毎日一定時刻にプロセスを自動起動するには、ゲートウ
ェイ装置がUNIX OS のもとで動作するのであれば、UNIX
OS に備えられているタイマ機能（cron）を使用する。
これは、UNIX OS に関連してよく知られている機能であ
るので、その詳細についてはここでは説明しない。な
お、UNIX OS 以外のＯＳでも、同様の機能が提供されて
いることが多い。

【０１３８】図３に、本願発明に係るプリフェッチプロ
セスの制御の流れを示した。このプロセスを実現するた
めのプログラムは、たとえば図１６のメモリ２０６内に
配置され、ＣＰＵ２０２によって実行される。このプロ
セスとネットワークおよびファイル装置２１６との入出
力には、それぞれネットワークＩ／Ｏインタフェース４
０２とＩ／Ｏインタフェース２０２とが使用される。

【０１３９】図３を参照して、まずステップ１で第１の
proxy プロセスのアクセスログファイルをｎ日分収集す
る。この収集の具体的な手順は次のとおりである。

【０１４０】第１のproxy プロセスのアクセスログファ
イル名称は、毎日名称が変わるように第１のproxy プロ
セスにより設定できる。たとえばログファイル名称の末
尾に、日付が入るようにすることができる。すると、ロ
グファイルとして次のようなものが生成されるであろ
う。

【０１４１】

【表１】

【０１４２】最新のｎ日分のログファイルを収集するた
めには、これらログファイルの名称リストを日付の降順
でソートすると便利である。UNIX OS のもとでは、この
ようなファイルの名称リストを日付の新しいものから順
に並べるには/bin/ls コマンドを−ｔオプションを指定
して起動すればよい。そのようなコマンド例とその結果
とを次に示す。

【０１４３】

【表２】

【０１４４】これらのファイルリストから最近のたとえ
ば７日分のログファイル名称を抽出することにする。こ
の場合には、UNIXに標準的に搭載されている/usr/ucb/h
eadコマンドを用いて先頭の７行を抽出すればよい。hea
dコマンドは、標準入力から先頭の指定行数を標準出力
に出力する。そこで、ls -t コマンドの標準出力をhead
コマンドの標準入力とすれば上述の最近の７日分のログ
ファイル名称を抽出できる。このためには、ls -t のコ
マンドとheadコマンドとを“｜”を使って繋ぎUNIX OS
に渡せばよい。このように“｜”を使って標準入出力を
接続することは、UNIXでは普通に行なわれている。なお
このような標準入出力の接続が行なえないOSのもとでこ
のようなデータに対する連続的な処理を行なう場合に
は、他の方式を使用する必要があるが、通常のＯＳでは
そのためのツールが装備されているであろう。

【０１４５】上述の接続後のコマンドとその結果とを次
に示す。

【０１４６】

【表３】

【０１４７】次に、図３のステップ２で、プリフェッチ
アクセスリストを作成する。このアクセスリストは１つ
のファイル“workfile.txt”にまとめられるものとす
る。このファイルは、その１行ごとに過去のアクセスフ
ァイルオブジェクトを記録したものとなる。したがって
このファイルを作成するために、以下のような条件でプ
リフェッチすべきファイルオブジェクト名称を含むアク
セスログを選択する。

【０１４８】（１）ＨＴＴＰコマンド文字列がファイ
ルオブジェクトリード要求（ＧＥＴ）であり、かつ
（２）ファイルオブジェクト名称のプロトコル部分が
httpであり、かつ（３）ファイルオブジェクト名称が
プリフェッチに適するものであること（プリフェッチに
適さないものを除外すること）。

【０１４９】以上の条件を使ってアクセスログを抽出し
リストを作る。さらにファイルオブジェクト名称のフィ
ールドだけをこのリストから抜出し、プリフェッチすべ
きファイルオブジェクト名称からなるプリフェッチアク
セスリストを作成する。

【０１５０】上述の条件（２）は、プリフェッチする意
味のあるファイルオブジェクト名称のみを抽出するため
である。第１および第２のproxy プロセスとして、上に
述べたように本実施の形態ではDeleGateソフトウェアを
使用している。このproxy ソフトウェアがキャッシュフ
ァイルを生成するプロトコルはhttpプロトコルのみであ
る。したがってプリフェッチして意味があるのはそのよ
うなhttpプロトコルに従ったアクセスログのみである。
それ以外のプロトコルはプリフェッチしてもキャッシュ
処理の対象とはならないので無意味である。

【０１５１】条件（３）に示すようにプリフェッチに適
さないファイルオブジェクト名称として、ＵＲＬ中に
「？」を含むものなどがある。？を含むＵＲＬ表記は、
サーバ計算機に対してクライアントユーザから文字列を
人手で入力する場合などに使われる。そのためこの文字
を含むＵＲＬ表記を有するファイルオブジェクトをプリ
フェッチすると、予期せぬ結果を招くおそれがある。こ
のステップ２の処理をUNIX OS のもとで行なうには、Ｏ
Ｓとともに提供されている次のようなコマンド群を使用
すればよい。

【０１５２】

【表４】

【０１５３】たとえば次のコマンドを入力することによ
り、このステップ２の処理を経たものがファイル“work
file.txt”にリストとして出力される。

【０１５４】

【表５】

【０１５５】この間の経過を以下に説明する。“workfi
le.txt”にあるアクセスログの形式は既に述べたように
次のとおりである。

【０１５６】

【表６】

【０１５７】したがって“workfile.txt”を標準出力
し、それをｇｒｅｐ −ｖ ”＼？”に入力することで
？を含まない行を抽出して標準出力に出力する。それを
さらにｇｒｅｐ ”＼”ＧＥＴ”への入力とし、それに
よってＧＥＴコマンドであるもののみを抽出して標準出
力に出力する。

【０１５８】さらに空白がフィールド間の区切りである
と考えると、“workfile.txt”の各行の７番目のフィー
ルドがファイルオブジェクト名称に相当するので、ａｗ
ｋコマンドを使用してこのファイルオブジェクト名称部
分のみを抽出する。さらにこのファイルオブジェクト名
称部分のプロトコル部分がｈｔｔｐである行のみを抽出
するために、grep "＾http://"でフィルタリングしてい
る。なおこのコマンドパラメータのうち＾は行の先頭を
示している。

【０１５９】このようにステップ２でworkfile2.txt に
出力されたプリフェッチアクセスリストは、内部ネット
ワークの複数のクライアント計算機からのサーバ計算機
へのアクセス記録である。したがってこのリストには同
じファイルオブジェクト名称が何度も出現する可能性が
ある。そこで、図３のステップ３で、このＵＲＬリスト
をファイルオブジェクト名称の出現頻度順にソートし、
かつ同じＵＲＬについては重複しないように１つにまと
める。

【０１６０】UNIXでは、このようなソート作業は、ＯＳ
とともに提供されている次のコマンド群を用いて行なう
ことができる。

【０１６１】

【表７】

【０１６２】具体的には次のコマンドとなる。

【０１６３】

【表８】

【０１６４】すなわちworkfile2.txt でＵＲＬだけにな
ったファイルを標準出力に出力し、これをｓｏｒｔの標
準入力とし、ファイルオブジェクト名称をアルファベッ
ト順に並べる。workfile2.txt の例を次に示す。

【０１６５】

【表９】

【０１６６】workfile2.txt ｜ sort の結果は次のよう
にアルファベット順（ＡＳＣＩＩコード順）になる。

【０１６７】

【表１０】

【０１６８】さらにこの出力をuniq -c の標準入力に入
力すると同一ファイルオブジェクト名称の行が集約さ
れ、かつ出現頻度が第１フィールドとして付加されて各
レコードが出力されるので、その出力は次のようにな
る。

【０１６９】

【表１１】

【０１７０】これらの第１フィールドを数値と考え、大
きいものから順にソートする。そのためにはsort -n -r
の標準入力に表１１の結果を与える。この結果各レコー
ドは出現頻度順に並べられ、その結果は次のようにな
る。

【０１７１】

【表１２】

【０１７２】すなわち表８のコマンドを実行した結果の
workfile3.txt というファイルは、出現頻度順に１行に
１個のファイルオブジェクト名称の並んだプリフェッチ
アクセスリストとなる。

【０１７３】さらに図３を参照して、ステップ４で、プ
リフェッチアクセスリスト２５の１行が読出せるか否か
を調べる。読出される行がない場合にはプリフェッチア
クセスリストの最後であるからこの処理は終了する。読
出す行がある場合にはステップ５に進む。

【０１７４】ステップ５では、読出した１行のファイル
オブジェクト名称をもとに第２のproxy プロセス３４を
用いて、サーバ計算機に対してネットワークアクセスを
する子プロセスを起動する。この子プロセスをプリフェ
ッチ子プロセスと呼ぶ。この子プロセスの終了を待って
処理をステップ４に戻し、ステップ４とステップ５との
処理を繰返すプリフェッチプロセスループを形成する。

【０１７５】なお、図３には示されていないが、ステッ
プ１からステップ５の処理により生成されたプリフェッ
チプロセスループを、指定時刻に強制終了するようにＯ
Ｓのタイマをセットする。ＯＳタイマは、UNIX OS に標
準的に提供されているａｔコマンドを利用して指定時間
動作を指定することにより行なえる。より具体的には、
上記したステップ１からステップ５によるプリフェッチ
プロセスのプロセスＩＤ番号を使用して次のコマンドを
ＯＳに与える。

【０１７６】

【表１３】

【０１７７】このコマンドにより、８時００分にプロセ
スを終了させるkill命令を発行するように、ＯＳに対し
て予約をすることができる。

【０１７８】なおネットワークアクセス部の実現方法と
しては、プリフェッチプロセスから直接ＨＴＴＰプロト
コルを発生すればよい。しかしUNIXで一般に利用されて
いるｌｙｎｘ（参考文献６参照）などのＷＷＷクライア
ントプログラムを利用すると、ＨＴＴＰプロトコルを発
生するプログラムを新たに製作しなくともＨＴＴＰプロ
トコルに従ったプリフェッチ子プロセス操作を実現でき
る。その方法を以下に説明する。

【０１７９】ｌｙｎｘはUNIX OS の上で動作するプログ
ラムであるので、以下の説明ではUNIXの記法を使用す
る。

【０１８０】ｌｙｎｘでは次のコマンドを指定すれば、
指定ＵＲＬを読出してtemp＿fileというファイルに書込
むことができる。

【０１８１】

【表１４】

【０１８２】さらにproxy プロセス経由のアクセスも、
UNIX OS の環境変数http＿ proxyを設定することによ
り、ｌｙｎｘから利用可能である。また、proxy プロセ
スがDeleGateのようなproxy ソフトウェアであれば、Ｕ
ＲＬ表記にproxy を指定することによりproxy 経由のア
クセスが可能である。これについては参考文献１２を参
照されたい。

【０１８３】後者の方式を採用する場合について以下説
明する。proxy プロセスが、ネットワークアドレスがpr
oxyserver であるゲートウェイ計算機のＴＣＰ／ＩＰの
１０００１番のポートを利用しているプロセスであるな
らば、このproxy プロセス経由でサーバ計算機のファイ
ルオブジェクトhttp://www.xxx.co.jp/test/index.html
をアクセスするためには次の表１５のコマンドを指定す
ればよい。

【０１８４】

【表１５】

【０１８５】したがって本願発明を実施する際には、同
様にしてproxy プロセスを第２proxy プロセスのポート
に設定してやればよい。

【０１８６】本願発明ではこのようなファイルオブジェ
クト（ＵＲＬ）のプリフェッチにより、第１のproxy プ
ロセスの管理するキャッシュファイルをｎ×２４／Ｍ倍
に増やし、かつ最新状態に保つことを目的としている。
temp＿file自体は利用されないので、このファイルは捨
てても構わない。

【０１８７】図３のステップ１では、ｎ日分アクセスロ
グファイルを集めた。このｎという数字は、キャッシュ
ファイルの最大容量とファイル転送実績から定めればよ
い。たとえば１ＧＢのキャッシュファイル装置に１日当
り１００ＭＢのキャッシュデータが蓄積されるようであ
れば、ｎ＝５程度に定めればよい。これにより、プリフ
ェッチは５００ＭＢ程度の容量となり、キャッシュファ
イル装置が溢れることはない。このように、キャッシュ
ファイルの蓄積の実績を考慮することにより、キャッシ
ュファイルを溢れさせないような数字ｎを容易に算出す
ることができる。

【０１８８】上述のようなプリフェッチプロセスは、内
部ネットワークから外部ネットワークにクライアント計
算機ユーザのアクセスがあまりない時間帯を利用して起
動することができる。こうすることにより、プリフェッ
チプロセスによるファイルオブジェクトアクセスが、内
部ネットワークユーザによる外部ネットワークへのアク
セスを妨げることがないように運用することができる。

【０１８９】上述の第１の実施の形態においては、プリ
フェッチプロセスは、クライアント計算機の利用が少な
くなる２１時００分より起動し翌日の８時００分には遅
くとも終了するようにした。この場合、翌日に８時００
分にプリフェッチプロセスがまだ動作しているときに
は、これを強制終了させるようにした。このようにある
時刻からプリフェッチプロセスを開始し、別の時刻には
強制的に終了させることにより、プリフェッチリストが
大きくて定められた時刻までにプリフェッチが終了しな
い場合でも、クライアント計算機の利用が増加し始める
時間帯にはプリフェッチプロセスは強制終了される。こ
れにより、クライアント計算機によるproxy サーバ装置
の利用が妨げられることはない。

【０１９０】第１の実施の形態では、第１のproxy プロ
セスのキャッシュ有効期限Ｍは２４時間に設定されてい
る。したがって夜間にプリフェッチプロセスにより更新
されたキャッシュデータの内容は、翌朝から翌晩の２１
時までは少なくとも有効である。

【０１９１】上述のproxy サーバ装置を使用すると、次
のような効果を得ることができる。キャッシュファイル
の内容は、ユーザにとっては最近の２４時間以内に更新
された情報である。その一方でそうした情報が過去ｎ日
の間にアクセス要求があったファイルオブジェクトに対
して保持されている。すなわちキャッシュファイルには
ｎ日分のキャッシュデータが蓄積されている。キャッシ
ュヒット率は、キャッシュされているデータ量が多くな
れば高くなることは既に図１３を参照して説明した。キ
ャッシュファイルの蓄積期間を２４時間とし、過去ｎ日
分のアクセスログを使用してプリフェッチを行なった場
合、キャッシュヒット率が３倍以上となることが経験的
にわかっている。

【０１９２】また、第１のproxy プロセスのキャッシュ
有効期限Ｍ時間よりも小さいかまたは等しい時間間隔で
上述のプリフェッチを行なうようにすれば、キャッシュ
ファイルが常に有効期限内に保たれているのは明らかで
ある。したがってプリフェッチから次のプリフェッチま
での間、プリフェッチの効果が有効に保たれる。

【０１９３】［実施の形態２］次に本願発明のゲートウ
ェイ装置の第２の実施の形態を説明する。この実施の形
態２は、実施の形態１と同様であるが、実施の形態１に
対応するフローチャート（図３参照）のステップ３およ
びステップ４を改良したものである。

【０１９４】実施の形態１では、ステップ４において、
プリフェッチアクセスリストからファイルオブジェクト
名称を１つずつ取出し、第２のproxy プロセスを通じて
外部ネットワークにアクセスしてファイルオブジェクト
を取得している。しかしプリフェッチアクセスリストの
行数が大きくなると、この方法では開始からすべてのア
クセスの終了までに長時間を要する場合があり得る。

【０１９５】ところで、ＷＷＷシステムが利用するＴＣ
Ｐ／ＩＰプロトコルを使用したネットワークでは、通信
はパケット単位で行なわれる。そのためある計算機が、
外部ネットワーク上の複数個のサーバ計算機と同時通信
を行なうことが見掛け上可能である。そこで、図３に示
すステップ５で起動されるプリフェッチ子プロセスは、
複数個同時に起動し並列に動作させることができる。

【０１９６】ファイルオブジェクトアクセスは、外部ネ
ットワーク上のさまざまな経路を通じて行なわれる。経
路の途中に転送速度の小さな経路がありそこがボトルネ
ックとなる場合があり得ることや、外部ネットワーク上
のサーバ計算機自身に大きな作業負荷がかかるためにア
クセス要求に即座に応答することができない場合などが
あり得る。したがって実際のファイルオブジェクトの転
送速度は、proxy サーバ装置と外部ネットワークとを結
ぶ最初の通信路の最大転送速度よりも小さな転送速度と
なるのが通常である。

【０１９７】たとえばproxy サーバ装置と外部ネットワ
ークを結ぶ通信路（図１６における通信路２７）の最大
転送速度が６４ｋｂｐｓであっても、海外にあるサーバ
計算機からの実際の転送速度がその１０分の１以下であ
ることはしばしばである。したがってproxy サーバ装置
と外部ネットワークとを結ぶ最初の通信路の最大転送容
量の範囲内で、同時に複数個のネットワーク接続を実施
することが可能である。すなわち複数個のプリフェッチ
子プロセスを起動して、複数個のファイルオブジェクト
を同時に取得する。これにより通信路の転送容量が１０
０％近く使用される状態にすることができる。

【０１９８】そこで、同時に複数のプリフェッチネット
ワーク接続を実行するプリフェッチ子プロセスの最大並
列実行数を予め定めておく。この数をMAXPROCESS数と
し、以下に述べる各ステップではメモリ（図１６のメモ
リ２０６）内に置かれる定数である。

【０１９９】以下その具体的な手順について、図４を参
照して説明する。図４に示されるフローチャートにおい
て、ステップ１からステップ４までは、図３に示すステ
ップ１〜ステップ４とそれぞれ同じである。したがって
これらステップについては詳しい説明は繰返さない。図
４では、図３のステップ５に代えてステップ５．１．２
〜５．２．４が設けられている。なお図４に示す動作を
行なうに先立って、メモリ中にprocesses 変数を定義し
ておく。processes 変数は、現在バックグラウンドで走
行しているプリフェッチ子プロセスの数を示す。

【０２００】まずステップ５．２．１では、ＵＲＬプリ
フェッチアクセスリストに表われたファイルオブジェク
ト名称の行を１つ取出す。そして第２のproxy プロセス
を使ってこのファイルオブジェクトをアクセスするプリ
フェッチ子プロセスを、バックグラウンドプロセスとし
て１つ起動する。なおUNIX OS においてプロセスは通常
バックグラウンドでも実行させることが可能である。あ
るプロセスをバックグラウンドで実行させるには、コマ
ンドラインに＆を付けてそのプロセスを起動すればよ
い。具体的なコマンド例を次に示す。

【０２０１】

【表１６】

【０２０２】続いてステップ５．２．２で、バックグラ
ウンドで走行しているプリフェッチ子プロセスの数を数
え、processes 変数に代入する。

【０２０３】ステップ５．２．３では、processes 変数
が、予め指定された最大プリフェッチ子プロセス数MAXP
ROCESS未満かどうかについての判定が行なわれる。proc
esses 変数がMAXPROCESS未満であれば制御はステップ４
からステップ５．２．１に戻り、さらにプリフェッチ子
プロセスがバックグラウンドで起動される。

【０２０４】processes 変数が指定の最大プリフェッチ
子プロセス数MAXPROCESS以上であれば、ステップ５．
２．４で、一定時間動作を休止（sleep ）して（たとえ
ば１０秒）再びステップ５．２．２に制御を戻す。以
下、ステップ５．２．２〜５．２．４の処理を繰返し行
ない、先行のプリフェッチ子プロセスが終了している場
合には新たなプリフェッチ子プロセスを起動し、全体と
してプリフェッチ子プロセスの数がMAXPROCESS以下とな
るようにする。

【０２０５】以上のような手順に従って同時処理を進め
ることで、プリフェッチの開始から終了までの時間を短
縮することができる。そのため既に説明した指定終了時
刻までの間に、より多くのファイルオブジェクトをプリ
フェッチすることが可能になる。実施の形態１と比較し
てキャッシュファイルにプリロードすることができるフ
ァイルオブジェクトの量を増やすことができるので、結
果としてキャッシュヒット率を高めることができる。実
験によればMAXPROCESS数として１０から２０の値をとれ
ば、プリフェッチ時間を十分に短縮することができるこ
とが確認されている。

【０２０６】［実施の形態３］続いて実施の形態３に係
るproxy サーバ装置について説明する。実施の形態３の
装置は、実施の形態２の装置をさらに改良したものであ
る。より具体的には、図４に示すステップ５．２．１か
らステップ５．２．４で行なわれる処理がより高速に行
なわれるように、ステップ３をさらに改良したものであ
る。その処理の流れを図５に示す。

【０２０７】実施の形態１および２では、プリフェッチ
子プロセスをMAXPROCESS以下の範囲内で同時に起動し、
並列に処理を進めることによりプリフェッチ時間の短縮
を図っていた。

【０２０８】しかし、実施の形態１および２のステップ
１からステップ３の手順で作成されたプリフェッチアク
セスリストの性質として、外部ネットワーク上の同一の
サーバアドレスが連続して表われることがしばしばであ
る。これは、既に説明したようにＷＷＷシステムにおい
て、クライアント計算機側で表示されるサーバ計算機の
１つの情報ページが、テキストと複数個のグラフィック
オブジェクトなど、複数個のファイルオブジェクトから
構成されていることが多いためである。たとえば図２に
示したような情報ページは、テキストとグラフィック混
じりのＷＷＷデータである。このデータを構成するファ
イルオブジェクトは次の７つである。

【０２０９】

【表１７】

【０２１０】このようにある情報ページが複数個のファ
イルオブジェクトで構成されている場合、これらはほぼ
同時に、連続してアクセスされ、したがってプリフェッ
チリストにもこれらのファイルオブジェクト名称が連続
して表われるであろう。すると、これらファイルオブジ
ェクト名称を順に取出し同時に複数個取得するプリフェ
ッチ子プロセスを起動した場合、特定のサーバのみに対
するアクセスが同時に発生することになる。一般にサー
バ計算機は、同時に複数のアクセスに対処可能なように
は構成されているが、１度に多くのアクセスが集中すれ
ば当然その応答は悪くなる。そのためこのようなアクセ
ス方法をとれば、アクセスが集中するサーバ計算機が、
プリフェッチプロセスのボトルネックとなり得る。

【０２１１】そこでこの実施の形態３では、プリフェッ
チアクセスリストを、その元々の順序そのものではな
く、特定のサーバにアクセスが集中しないような順序に
並べ換える。すなわちプリフェッチアクセスリスト中の
ファイル名称をインターリーブ処理させる。この場合、
ファイルオブジェクト名称をランダムに並べ換えれば、
特定のサーバ計算機にアクセスが集中する可能性を最も
低くすることができる。しかし、プリフェッチアクセス
リストは元々出現頻度順で作成されており、かつ出現頻
度順にファイルオブジェクトを取得した方がヒット率の
向上を期待できる。そのためプリフェッチアクセスリス
ト上でのファイルオブジェクト名称の出現順序をある程
度は保つことが望ましい。たとえばプリフェッチの終了
時刻までにすべてのプリフェッチアクセスリストのファ
イルオブジェクトのプリフェッチが完了しない場合もあ
り得るだろう。そうした場合には、出現頻度の高いもの
が確実にプリフェッチを終了しているようにした方がよ
い。

【０２１２】実測によれば、このようなプリフェッチア
クセスリスト中で、同一サーバアドレスが連続する数
は、たかだか数十である。そこで、プリフェッチアクセ
スリストを、この数十という数よりもある程度大きな数
の行、たとえば千行程度のブロックに分割する。そして
それらブロック各々の内部で、ファイルオブジェクト名
称の順番を入替える。そのように各ブロックごとに行が
入替えられたプリフェッチアクセスリストの先頭から実
施の形態２と同じようにファイルオブジェクトのプリフ
ェッチを実行する。こうすることで、各ブロックの中で
は各行の順序が入替えられているので、同一サーバアド
レスが連続して出現する可能性は少なくなる。一方でブ
ロックの順番は保たれているので、最初のプリフェッチ
アクセスリストにあった出現頻度順は、ブロックサイズ
の粒度で保たれている。したがって出現頻度の高いもの
を優先的にプリフェッチしながら、特定のサーバ計算機
のみに同時にアクセス要求が集中するという問題を解決
することができる。

【０２１３】以下この実施の形態３での処理手順を図５
を参照して説明する。ブロックサイズをBLOCKSIZE 変数
とする。この変数はメモリ内に置かれる。以下の処理で
は、順番を入替える（インターリーブする）際に、乱数
を使用する。もちろんこれは簡単に実現できる例として
挙げたものであって、他の方法を使用して入替え処理を
行なってもよい。

【０２１４】図５に示される手順は、図４に示される実
施の形態２の手順のステップ３に代えて、ステップ３．
３．１および３．３．３を用いる。他のステップについ
ては実施の形態２と同じであるので、それらについての
詳しい説明はここでは繰返さない。

【０２１５】ステップ３．３．１では、プリフェッチア
クセスリストを、ファイルオブジェクト名称の出現頻度
順に並べ換え、かつ同じファイルオブジェクト名称につ
いては重複しないように１つにまとめる処理を行なう。
この処理は図４のステップ３の処理とほぼ同様である。

【０２１６】次いでステップ３．３．２では、ファイル
オブジェクト名称をインターリーブ処理して行を入替え
る処理を行なう。より具体的には次の手順に従う。

【０２１７】まずプリフェッチアクセスリストのすべて
の行に乱数［ｉ］を付与する（ｉは行番号を示す。）。
乱数計算の方法としては種々考えられるが、この実施の
形態では乱数は次の式に従って計算する。

【０２１８】

【数６】

【０２１９】ただしｒａｎｄ（）という関数は、２の
３２乗の範囲の乱数を生ずる関数であるものとする。こ
の式の第１項は、ｒａｎｄ（）という関数で得られた
乱数に対しBLOCKSIZE 変数の剰余をとったものである。
したがってこの第１項は０からBLOCKSIZE −１までの範
囲の乱数（整数）となる。

【０２２０】また上式の第２項は、次のような意味を持
つ。プリフェッチアクセスリストを各々BLOCKSIZE 行を
含むブロックに分割し、各ブロックに対して０から始ま
る整数のブロック番号を付けるものとする。第２項は、
このようにして付けられたブロック番号にBLOCKSIZE を
かけたものと等しい。したがってこれはBLOCKSIZE 数の
整数倍であり、かつ０から始まって増加していく。第２
項はBLOCKSIZE が３であれば０、０、０、３、３、３、
６、６、６、…となる。

【０２２１】このような乱数［ｉ］をプリフェッチアク
セスリストの各行の先頭フィールドに付与する。そして
各行を、第１フィールドの数の小さい順にソートし、さ
らに各行の先頭から乱数［ｉ］を取り除く。こうした処
理によりBLOCKSIZE 行からなるブロックごとに、行がラ
ンダムにインターリーブされたプリフェッチアクセスリ
ストが生成される。

【０２２２】上述のようにこのとき、最初のプリフェッ
チアクセスリストにあった出現頻度順は、ブロックサイ
ズの粒度で保たれている。

【０２２３】以下に、乱数によるプリフェッチアクセス
リスト内の各行のインターリーブの例を具体的に示す。
まずオリジナルのプリフェッチアクセスリストが次のよ
うなものであるとする。

【０２２４】

【表１８】

【０２２５】これをBLOCKSIZE ＝10として既に述べた式
に従ってそれぞれ第１フィールドに乱数を付与すると次
のようになる。

【０２２６】

【表１９】

【０２２７】さらにこれを第１フィールドの数字の昇順
にソートすると次のようなリストが得られる。この例で
はBLOCKSIZE が１０と小さいため、十分にインターリー
ブされてはいないが、各１０行単位の内部で行の順番が
ランダムに入替えられていることがわかる。なおこの表
はインターリーブのための手順を示す一例にすぎないこ
とに注意されたい。

【０２２８】

【表２０】

【０２２９】このインターリーブ処理をした後に実施の
形態２と同様にプリフェッチ子プロセスの並列実行を行
なう。同一のサーバ計算機をアドレスとして含むファイ
ルオブジェクトがプリフェッチアクセスリスト中に連続
して表われることが避けられるため、特定のサーバ計算
機へアクセスが集中することが避けられる。その結果各
サーバ計算機に負荷が集中することなく、サーバ計算機
から迅速に必要なファイルオブジェクトをプリフェッチ
することができ、結果としてプリフェッチ処理全体の時
間を短縮化することができる。キャッシュファイルにプ
リフェッチされるキャッシュデータの量を増やすことが
できるので、キャッシュヒット率を高めることができ
る。

【０２３０】［実施の形態４］続いて実施の形態４のゲ
ートウェイ装置であるproxy サーバ装置について説明す
る。この実施の形態４は、実施の形態３をさらに改良し
たものである。実施の形態３では、プリフェッチ子プロ
セス数としてMAXPROCESS数を最大とするようなプリフェ
ッチ子プロセス数の起動の制御を行なっていた。しかし
こうした処理では、たとえばクライアント計算機からの
ファイルオブジェクトへのアクセス要求が多く発生して
いるときにも上記したMAXPROCESS数だけのプリフェッチ
子プロセス数が起動されてしまうことがあり得、その結
果クライアント計算機によるファイルオブジェクトへの
アクセス要求に対する応答が低下してしまうおそれがあ
る。この実施の形態４は、そうした問題を解決するため
の改良である。

【０２３１】実施の形態４では、クライアント計算機の
ユーザが第１のproxy プロセスを利用して外部ネットワ
ークのサーバ計算機に多数アクセスするような時間帯に
は、プリフェッチ子プロセスが起動される数を少なくす
ることにより、内部ユーザによるネットワーク利用活動
を妨げないようにしている。

【０２３２】具体的な処理手順を図６に示す。図６のフ
ローチャートは、図５に示すフローチャートのステップ
５．２．１〜５．２．４に代えてステップ５．４．１〜
５．４．４を採用したものであり、動的にプリフェッチ
子プロセスのプロセス数を制御する点に特徴がある。他
のステップは、第１〜第３の実施の形態において説明し
たものとそれぞれ同じであるので、ここではその詳細な
説明は繰返さない。

【０２３３】図６を参照して、ステップ５．４．１で、
プリフェッチアクセスリストに現れたファイルオブジェ
クト名称から１行を抽出する。そして第２のproxy プロ
セスを使ってそのファイルオブジェクトにアクセスする
ためのプリフェッチ子プロセスをバックグラウンドプロ
セスとして１つ起動する。

【０２３４】続いてステップ５．４．２で、バックグラ
ウンドで走行しているプリフェッチ子プロセスの数と、
第１のproxy プロセスにより起動されているネットワー
クアクセス中継子プロセスの数を調べ加算して、proces
ses 変数に代入する。

【０２３５】続いてステップ５．４．３で、processes
変数が、予め指定された最大プリフェッチ子プロセス数
MAXPROCESSより小さいか否かについての判定が行なわれ
る。小さければ制御はステップ４に戻り、上述した新た
なプリフェッチ子プロセス起動の処理が行なわれる。

【０２３６】processes 変数が、予め指定されたMAXPRO
CESS以上であれば制御はステップ５．４．３からステッ
プ５．４．４に進み、一定時間（たとえば１０秒）休止
してステップ５．４．２に制御を戻す。

【０２３７】図６に示すような処理手順に従って、この
実施の形態４のproxy サーバ装置は動作する。プリフェ
ッチ子プロセスの個数と、第１のproxy プロセスを利用
している内部ユーザのネットワークアクセスの中継子プ
ロセス数との「合計」が一定となるように、プリフェッ
チ子プロセスが新たに起動されるのを制御する。第１の
proxy プロセスを利用しているユーザによるネットワー
クアクセスの子プロセスがMAXPROCESS数以上であれば、
プリフェッチ子プロセスは新たには起動されず起動待ち
となる。

【０２３８】内部のユーザが第１のproxy プロセスを多
数利用している時間帯に上述のプリフェッチプロセスを
実行しても、プリフェッチ子プロセスには低い優先権し
か与えられないので、内部ユーザのネットワーク利用活
動を妨げないようにすることができる。プリフェッチプ
ロセスを、内部ユーザの活動時間帯に始動させても、内
部ユーザのネットワーク利用は妨げられない。またプリ
フェッチプロセスが、クライアント計算機のユーザの活
動時間に食い込んでもやはり内部ユーザのネットワーク
利用は妨げられない。

【０２３９】その結果、プリフェッチプロセスの開始か
ら終了までより長時間を使用してプリフェッチを行なう
ことができる。そのため多くのファイルオブジェクトを
プリフェッチすることが可能になり、したがってキャッ
シュデータの量を増やすことができる。上述のキャッシ
ュデータの量とキャッシュヒット率との関係から、結果
としてキャッシュヒット率を高めることができる。

【０２４０】これは、「数１」に示された式を参照し
て、ヒット率を高めるので、平均ファイルオブジェクト
転送速度を増加させるという効果を奏する。別の見方を
すれば、このようにすることにより同じ平均ファイルオ
ブジェクト転送速度を維持しながら、内部ネットワーク
のより多くのユーザの利用を可能にするということがで
きる。

【０２４１】［実施の形態５］次に、実施の形態５のゲ
ートウェイ装置の一例であるproxy サーバ装置について
説明する。既に延べた実施の形態１〜４では、夜間など
内部ユーザが外部ネットワークを利用しない時間帯に、
ｎ日分（＝ｎ×２４時間＝Ｎ時間）のプリフェッチを実
行した。キャッシュファイルについては、有効期限をＭ
時間であるとすると、Ｍ時間以上古いキャッシュファイ
ルについては定期的に消去していた。こうした古いキャ
ッシュファイルの消去については上述の実施の形態１〜
４では言及していない。

【０２４２】UNIX OS であれば、一定時間以上変更のな
いファイルはｆｉｎｄコマンドを利用して消去可能であ
る。下に挙げるのは、毎日一定時刻に起動されるキャッ
シュ消去コマンドの一例である。cache というディレク
トリの下にある、１日以上変更のない古いファイルが、
このキャッシュ消去コマンドにより消去される。

【０２４３】

【表２１】

【０２４４】ところで、実施の形態１〜４のproxy サー
バ装置では、午後９時から翌朝午前８時までの間にプリ
フェッチを実施していた。これにより夜間のトラフィッ
クが、昼間の内部ユーザによるアクセスのｎ倍となる。

【０２４５】実際には、キャッシュが有効期限を過ぎて
いる場合には、DeleGateのような一般的に使用されてい
るproxy プロセスにおいては、ＨＴＴＰに従って次のよ
うなアルゴリズムが取られる。

【０２４６】（１）外部ネットワークのサーバ計算機
に存在するファイルオブジェクトの取得要求（ＧＥＴ命
令）を出すときに、ＧＥＴ命令にキャッシュファイルの
時刻Ｔcache を付けて要求を出す。

【０２４７】（２）この要求を受けたサーバ計算機
は、その持っている対応するファイルオブジェクトの最
終変更時刻Ｔorg とＴcache とを比較する。

【０２４８】（３）そしてＴorg ＞Ｔcache のとき、
すなわちファイルオブジェクトの最終変更時刻よりもキ
ャッシュファイルの時刻のほうが古いときのみ、サーバ
計算機は当該ファイルオブジェクトをproxy サーバ装置
に対して転送する。すなわち、前回キャッシュされた時
刻以降に元のファイルオブジェクトが変更されている場
合のみ当該ファイルオブジェクトの転送が実行される。

【０２４９】（４）Ｔorg ＞Ｔcache ではない場合に
は、サーバ計算機は当該キャッシュファイルを使えとい
う応答コードをproxy サーバ装置に返答する。

【０２５０】上述のアルゴリズムによれば、実際には元
のデータのうち変更されているものだけがサーバ計算機
からproxy サーバ装置に転送される。変更されていない
場合には、キャッシュファイルの当該ファイルオブジェ
クトの最終変更時刻が、そうした確認がされた時刻に更
新される。

【０２５１】実施の形態５では、proxy プロセスのこの
ようなアルゴリズムを利用することにより、ネットワー
ク上のデータ転送量を減少させる。そのためこの実施の
形態５のproxy サーバ装置では、キャッシュファイル
（有効期限Ｍ時間）のキャッシュデータのうちで、Ｍ時
間以上古いものを定期的に必ず消去してしまうのではな
く、Ｍ＜Ｎ≦Ｅであるような時間Ｅを定め、これ以上古
いファイルオブジェクトのみを定期的に消去するように
している。これにより有効期限の過ぎたキャッシュファ
イルのファイルオブジェクトであっても、直ちには消去
されず、Ｅ時間内は有効に活用することができる可能性
がある。たとえばサーバ計算機に対するプリフェッチを
行なった際に、元データが変更されていないことが確認
されたデータは、改めてサーバ計算機からproxy サーバ
装置に転送する必要はない。キャッシュされているデー
タと元データとは一致しているためである。このとき、
キャッシュファイルへの書込時刻のみが更新される。結
果としてこのデータについては、プリフェッチが行なわ
れた時刻にサーバ計算機から新たに転送されたのと同じ
効果を得ることができ、プリフェッチ時のネットワーク
のデータ転送量を減少させることができる。

【０２５２】ここで、Ｎ＝Ｅとすると管理が簡単であ
る。時間Ｅとしては、キャッシュファイルが溢れない程
度であってかつなるべく大きな値を採用すればよい。Ｎ
＝Ｅとして、Ｎを主体に考えてこれを大きく取る場合を
考える。Ｎを大きく取れば、既に延べたようにプリフェ
ッチされるべきファイルオブジェクトが増えるので、キ
ャッシュファイルの蓄積量は、増大するはずである。し
かし実際にはプリフェッチは一定時刻に強制終了される
ので、実施の形態１〜４のようにプリフェッチにおいて
必ずデータ転送を行なっても、キャッシュファイルの蓄
積量はＮとともに増大するわけではない。ところがこの
実施の形態５の装置では、変更されていないファイルオ
ブジェクトについてはデータ転送を行なうことなく、か
つプリフェッチを行なったのと同じ効果を得ることがで
きる。したがって、キャッシュファイルの蓄積量は、実
は時間Ｅの大小に影響される。

【０２５３】実際の測定結果によれば、Ｅ／２４時間＝
ｎ＝７日のときに、全プリフェッチデータのうち６％程
度しかファイルオブジェクトのキャッシュへの再ロード
を引起こしていない。キャッシュファイルの最終変更時
刻情報のついた「条件付きＧＥＴ命令」による最終変更
時刻情報の転送量は、実際のファイルデータの転送と比
較して量的に無視し得るほど小さい。そのためこの実施
の形態５に従ったプリフェッチにより増加するトラフィ
ックは、サーバ計算機のファイルオブジェクトのうち、
キャッシュに格納された時刻以後に更新されたものにつ
いてのデータ転送に対するものだけである。実測例によ
ればプリフェッチによるトラフィックの増加は７日分×
０．０６＝０．４２日分である。

【０２５４】この実施の形態５のproxy サーバ装置で行
なわれるプリフェッチ処理によるキャッシュのヒット率
向上により、昼間のユーザの活動による外部ネットワー
クから内部ネットワークへのファイルオブジェクト転送
量は、約２０％減少していることが観察されている。し
たがって上述したプリフェッチによるトラフィックの増
加を考慮しても、１日のトータルで見れば、プリフェッ
チによる外部ネットワークからのデータ流量は量的に著
しく増えているわけではない。したがって外部ネットワ
ークのトラフィックをいたずらに増やすことなく、キャ
ッシュファイルの内容を新鮮に保つことができるという
利点が得られる。

【０２５５】［実施の形態６］ところで、以上の実施の
形態でのアクセスログの例を数４に示してある。数４に
示したアクセスログは、第１のproxy プロセスとしてDe
leGateソフトウェアを使用する場合のアクセスログ例で
あるが、これらのうち既に説明したもの以外の部分につ
いてここで説明する。これらは、サーバ計算機の状態コ
ード、ファイルオブジェクトのデータサイズ、キャッシ
ュ状況などである。

【０２５６】サーバ計算機の状態コードとは、サーバ計
算機がクライアント計算機からの要求に対して発する３
桁の数字で表わされる応答である。状態コードの最初の
数字は、状態コードのカテゴリを示しており、１、２、
３、４、５が使用される。２００番代の状態コードはク
ライアント計算機の要求を問題なく理解したことを示
す。たとえば状態コードが２００の場合には、要求が正
常に受付けられた旨を示す。３００番代の状態コードは
サーバ計算機が再転送の必要があることを示し、４００
番代の状態コードはクライアント計算機のエラーを示
し、５００番代の状態コードはサーバ計算機のエラーを
示している。また、１００番代の状態コードは将来のた
めに予約されており、現在は使用されていない。

【０２５７】ファイルオブジェクトのデータサイズと
は、ファイルオブジェクトのサイズをバイト数で示して
いる。キャッシュ状況とは、サーバ側データとキャッシ
ュ内容との関係を示すものである。キャッシュ状況が
「Ｈ」ならキャッシュヒット、「Ｎ」ならキャッシュが
存在せずに新たにキャッシュファイルにファイルオブジ
ェクトが書込まれたこと、「Ｏ」であればサーバ側デー
タがキャッシュ内容よりも新しいということを示す。

【０２５８】本発明の実施の形態６のゲートウェイ装置
では、このようなファイルオブジェクト転送記録を利用
する。

【０２５９】実施の形態６のゲートウェイ装置は、実施
の形態１〜５をさらに改善したものである。既に述べた
本発明のゲートウェイ装置では、利用される際にはクラ
イアント計算機による利用が少ない時間帯でのプリフェ
ッチの実行を行なうことが想定されている。しかしそれ
ら時間は夜間など、限られた時間に限定される。そのた
めプリフェッチできるファイルオブジェクトの量には制
限があり、プリフェッチ対象のファイルオブジェクトを
すべてプリフェッチすることができないことがある、と
いう問題点がある。実施の形態６のゲートウェイ装置は
こうした問題を解決すべく、短い時間に効率良くファイ
ルオブジェクトをプリフェッチすることを目的としてい
る。

【０２６０】図７に、本願発明の実施の形態６に係るゲ
ートウェイ装置の一例であるproxyサーバ装置５４の概
略のブロック図を、proxy サーバ装置５４が接続される
ネットワーク２５および内部ネットワーク２３とともに
示す。図７において、図１に示すproxy サーバ装置５３
と同一の部品には同一の参照符号および名称を付してい
る。それらの機能も同一である。したがって、ここでは
それらについての詳しい説明は繰返さない。

【０２６１】図７に示されるproxy サーバ装置５４が図
１に示されるproxy サーバ装置５３と異なるのは、第２
のproxy プロセス３４が、アクセスログ３９にプリフェ
ッチの伝送記録を書込むこと（４０）と、アクセスリス
ト３０から読出したファイルオブジェクトに対して第２
のproxy プロセス３４によるプリフェッチを行なわせる
点においては図１に示されるプリフェッチプロセス３６
と同様であるが、この新たに設けられたアクセスログ３
９の内容を参照し、アクセスログに含まれるファイルの
変更状況を表わす情報に従って、前回のプリフェッチ時
に変更が検出されたファイルオブジェクトをアクセスリ
スト３０からのファイルオブジェクトに優先してプリフ
ェッチするように第２のproxy プロセス３４を制御する
ためのプリフェッチプロセス４１を含んでいることであ
る。

【０２６２】第１のproxy プロセス１４、第２のproxy
プロセス３４およびプリフェッチプロセス４１がいずれ
もメモリ中に置かれ、ＣＰＵによって処理されるのは実
施の形態１の装置と同様である。

【０２６３】このproxy サーバ装置５４では、第２のpr
oxy プロセス３４は、ファイルオブジェクトのプリフェ
ッチの結果のアクセスログ３９を記録する。プリフェッ
チプロセス４１は、このアクセスログ３９を走査し、前
回のプリフェッチの結果、プリフェッチされたファイル
オブジェクトが、その前にプリフェッチされた時点以後
に更新されていたものの名称を抽出し、変更検出リスト
を作成する。変更検出リストを、名称順、出現頻度順に
並べることにより同一名称のものを取除いた上で、アク
セスリスト３０から抽出されたプリフェッチリストの前
部にマージする。そしてこのマージされたプリフェッチ
リストに従って第２のproxy プロセス３４のプリフェッ
チプロセスを実行させる。

【０２６４】前回のプリフェッチ時に、その前のプリフ
ェッチ以後変更されていたファイルオブジェクトは、以
後も比較的頻繁に変更される可能性が高い、ということ
ができる。したがって上述のように作成されたプリフェ
ッチリストは、変更の可能性の高いファイルオブジェク
トが前部に置かれたものである。そのためこれらは、規
定時間のうちでも最初の方でプリフェッチされる。変更
の可能性の低いものは、これらの後にプリフェッチされ
ることになるが、変更の可能性が低いので、既にフェッ
チされているデータで十分である可能性が高い。そのた
め限られた時間内に、変更可能性の高いファイルオブジ
ェクトを優先的にプリフェッチすることができ、キャッ
シュファイル１６の内容を新鮮に保つことができる。

【０２６５】以下、プリフェッチプロセス４１の動作を
詳しく述べるが、その概略についてまとめておくと次の
ようになる。

【０２６６】（１）第２のproxy プロセス３４のアク
セスログ３９から、過去の一定の日数分のログを集め
る。サーバ計算機側のファイルオブジェクトが、前回の
プリフェッチの結果その前のプリフェッチ以後変更され
ていたという情報を持っているファイルオブジェクトの
リストを、変更検出リストとして作成する。これらは、
前回のプリフェッチの結果、キャッシュファイルに書込
まれたファイルオブジェクトのリストでもある。

【０２６７】（２）第１のproxy プロセスのアクセス
ログファイル３０をもとに、過去の一定期間のファイル
オブジェクト名称を抽出し、プリフェッチアクセスリス
トを作成する。このプリフェッチアクセスリスト自体は
実施の形態１におけるものと同様である。

【０２６８】（３）（２）で作成されたプリフェッチ
アクセスリストの先頭部分に、（１）で作成された変更
検出リストをマージする。

【０２６９】（４）このようにして作成されたプリフ
ェッチアクセスリストに基づき、第２のproxy プロセス
３４を利用して、外部ネットワークのサーバ計算機か
ら、プリフェッチアクセスリストにあるファイルオブジ
ェクトをプリフェッチする。

【０２７０】（５）これによりキャッシュファイル１
６内に、第２のproxy プロセス３４によってファイルオ
ブジェクトが書込まれ、最新に維持される。このとき第
２のproxy プロセス３４は、アクセス結果をアクセスロ
グ３９に書込む。

【０２７１】図８および図９を参照して、このproxy サ
ーバ装置５４の動作をより詳細に説明する。なお図８お
よび図９に示されるフローチャートの各ステップをたと
えば「step１」、「step５」などと記載することにす
る。

【０２７２】step１第２のproxy プロセスのアクセスログファイルを、最近
のＰ日分収集する。なおアクセスログファイルは、各日
別に別々のファイルとして作成されるものとする。この
ログファイルはプリフェッチによるアクセスログであ
る。したがって、プリフェッチ時にサーバ計算機のファ
イルオブジェクトにアクセスした結果に従って、ファイ
ルオブジェクトが更新されたかどうかという情報を有し
ている。なお発明者の経験では、Ｐは２程度で十分であ
る。

【０２７３】第２のproxy プロセスのアクセスログファ
イル名称は、毎日名称が変わるように第２のproxy プロ
セスにより設定することができる。たとえばログファイ
ル名称の末尾に日付が入るようにすることができる。そ
の場合ファイル名称をたとえば"/usr/local/etc/delega
ted/10000.http. 日" という名称にすることができる。
例として７月１日から１０日までのログファイルの名称
を示すと次のようになる。

【０２７４】

【表２２】

【０２７５】最新のログファイルから順番に並べるため
に、UNIX OS の下では、/bin/ls コマンドを「-t」オプ
ションで起動する。具体的には次のとおりである。

【０２７６】

【表２３】

【０２７７】これにより次の結果を得ることができる。

【０２７８】

【表２４】

【０２７９】既に述べたようにＰ＝２で十分であるか
ら、このようにして並べ変えられたファイルリストから
最近の２日分のログファイル名称を抽出する。そのため
には、UNIX OS に標準的に搭載されている/usr/ucb/hea
d コマンドを用いる。headコマンドは標準入力から先頭
の指定行数を標準出力に出力するので、”｜”を使い、
ls -t の標準出力をheadコマンドの標準入力とすればよ
い。そうした標準出力の接続を行なったコマンドを次の
表２５に示す。

【０２８０】

【表２５】

【０２８１】上のコマンドを実行すると次の結果が得ら
れる。

【０２８２】

【表２６】

【０２８３】step２ここで、step１で収集した第２のproxy プロセスのアク
セスログファイルを１つのファイル"obsoletelist.txt"
にまとめる。なおこの名称は一例にすぎず、運用に応じ
て適当に定めることができる。

【０２８４】このように"obsoletelist.txt"というファ
イルにアクセスログファイルをまとめるとき、ファイル
オブジェクトがproxy サーバ装置５４を介してユーザに
中継された時刻と、プリフェッチを行なう時刻との間隔
に応じた重み付けを加える。すなわち、最新のアクセス
ログファイルに、古いアクセスログファイルよりも大き
な重み付けを加える。たとえば、単純にログファイルの
日付に注目して次のようにすることができる。表２５に
示したコマンドの実行の結果得られる出力は、日付の新
しいログファイルから順番に並んでいる。そのためUNIX
OS に標準的に搭載されているcat コマンドを利用して
次のように"obsoletelist.txt"ファイルを作成すること
ができる。

【０２８５】

【表２７】

【０２８６】表２７のようにcat コマンドを利用するこ
とにより、プリフェッチを行なう当日に残されたアクセ
スログは２回分とカウントされるのに対して、前日分の
アクセスログは１回分とカウントされる。したがって最
近アクセスされたファイルオブジェクトの出現頻度に、
より大きな重み付けが与えられたアクセスログリストが
残される。

【０２８７】step３上述のstep２で出力されたファイル"obsoletelist.txt"
の各行は、過去のプリフェッチによるアクセスファイル
オブジェクトの記録である。そこで、以下のような条件
に従ったファイルオブジェクト名称を含むアクセスログ
を選択する。

【０２８８】・httpコマンド文字列がファイルオブジェ
クトリード要求（GET ）であり、かつ・ファイルオブジェクト名称のプロトコル部分がhttpで
あるもの・特定の文字列パターンにマッチするものは除外・ファイルオブジェクト名称がプリフェッチに適さない
ものを除外・ファイルオブジェクトコードのデータサイズが巨大な
ものを除外・サーバ計算機の状態コードが特定のものを除外・ファイルオブジェクトのアクセスの結果、キャッシュ
が更新されたものをプリフェッチ以上の条件を使ってファイルオブジェクトを抽出する。
このようにして抽出されたリストは、前回のそのファイ
ルオブジェクトのアクセスの結果キャッシュが更新され
たもののみを含むから、これをファイルオブジェクトの
変更検出リストと呼ぶことができる。この変更検出リス
トに対して、まず出現頻度順のソートを行なった上で、
同一名称のファイルオブジェクトをまとめる。またファ
イルオブジェクト名称のフィールドだけを取出して、プ
リフェッチすべきファイルオブジェクト名称からなるプ
リフェッチアクセスリストを作成する。

【０２８９】プリフェッチに適さないと考えられるファ
イルオブジェクト名称として、URL中に”? ”を含むも
のがある。”? ”を含むURL 表記は、クライアントユー
ザが文字列を手操作により入力してサーバ計算機に対し
て渡す場合などに使われる。そのためこのURL 表記を含
む名称のファイルオブジェクトをプリフェッチすると、
ユーザに代わって機械が勝手に文字を入力したことにな
ってしまうので、有害である。

【０２９０】このようなファイルオブジェクト名称の抽
出作業は、UNIX OS で標準で提供されている次のような
コマンド部すなわち

【０２９１】

【表２８】

【０２９２】および、Ｃ言語などを用いて記述したプロ
グラム

【０２９３】

【表２９】

【０２９４】などを使って行なうことができる。なお表
２８および表２９において、左側にはコマンドおよびパ
ラメータと、プログラム読出のためのコマンドが、右側
にはそれぞれに対応する機能が、それぞれ示されてい
る。

【０２９５】たとえば次のコマンドを投入することによ
り、step３の処理を経たリストが標準出力に出力され
る。

【０２９６】

【表３０】

【０２９７】以下、その経過について説明する。"obsol
etelist.txt"にあるログファイルの形式は既に述べたよ
うに次のようになっている。

【０２９８】

【表３１】

【０２９９】末尾のキャッシュ状況は、第２のproxy プ
ロセスのサーバ計算機へのアクセス状況によって変化す
る。具体的には次のとおりである。

【０３００】「O 」：サーバ計算機のファイルオブジェ
クトの方がキャッシュのファイルオブジェクトより新し
かった場合「S 」：サーバ計算機のファイルオブジェクトとキャッ
シュのファイルオブジェクトとの最終変更時刻の比較に
より、両者が同じものであると判明した場合キャッシュ
状況はこの他にもさまざまなあるが、これらのキャッシ
ュ状況に関する情報は、プリフェッチを中継した第２の
proxy プロセスによりアクセスログ３９に書き出されて
いる。そこで、"obsoletelist.txt"を標準出力にcat コ
マンドで出力し、それをgrep 'O$' に入力することで、
行末が「O 」であるものが標準出力に出力される。なお
grepというコマンドもUNIX OS に標準的に搭載されてい
るものである。さらにこの出力を処理するためには、既
に述べたように”｜”を使い、この標準出力を次のコマ
ンドの標準入力とすればよい。

【０３０１】その標準出力を"grep -v" ＼?"の標準入力
とすることで”? ”を含まない行を抽出し、標準出力に
出力する。その出力を"grep"＼"GET" の標準入力に入力
する。その結果、コマンドが「get 」である行のみが抽
出され、標準出力に出力される。

【０３０２】このようにして得られた標準出力をgrep＿
datasize DATASIZE の標準入力に与える。この場合、DA
TASIZEには、予め指定されたファイルオブジェクトのデ
ータサイズの上限値が設定されている。この値はたとえ
ば実際のコマンドでは具体的な値に設定されている。こ
のコマンドの標準出力として、ファイルオブジェクトの
データサイズが定数 DATASIZE よりも小さい行のみが抽
出され標準出力に得られる。

【０３０３】さらにこの標準出力を、grep＿response r
esponse.txt の標準入力に与える。ここで、"response.
txt"は、予め抽出されるべき、サーバ計算機の状態コー
ドが記述されているファイルである。このコマンドの実
行により、サーバ計算機の状態コードが"response.txt"
に記述されている状態コードと一致する行のみが抽出さ
れ標準出力に出力される。

【０３０４】空白を区切りと考えると、表３１に示され
るアクセスログでは、７番目のフィールドがファイルオ
ブジェクト名称に相当する。そこで上述したgrep＿resp
onseresponse.txt の出力を、awk'｛print $7｝' の標
準入力に与えてファイルアクセスログからファイルオブ
ジェクト名称の部分のみを抽出する。

【０３０５】さらに、ファイルオブジェクト名称部分の
プロトコル名称がhttpである行のみを抽出する必要があ
る。そこで上述した出力をさらに"grep " ＾http://"の
標準入力に与える。なおここで" ＾" は行の先頭を示
す。以上のような処理の結果が標準出力に出力される。
なおこのようにして得られた標準出力は、次のstep４で
再び標準入力として使用される。

【０３０６】step４次に、step３で出力されたファイルオブジェクトのリス
トから、プリフェッチに好ましくないと思われるものを
取除く。具体的には、プリフェッチするのに好ましくな
いと思われるファイルオブジェクトが有すると思われる
文字列パターンを、除外パターンリストとして"exclud
e.txt" というファイルに予め格納しておく。このリス
トの追加変更は、ゲートウェイ管理者が行なう。

【０３０７】具体的には、プリフェッチしてわざわざキ
ャッシュを更新する必要はないと判断されるような内容
を含むファイルオブジェクト、サイズが巨大なため、プ
リフェッチすると他のファイルオブジェクトのプリフェ
ッチの妨げになるようなファイルオブジェクト、または
サーバ計算機に異常があり、プリフェッチする上で支障
があるファイルオブジェクトなどが考えられる。この"e
xclude.txt" ファイルの記載内容の例を表３２に示す。
もちろん表３２に示すものは仮定の例である。表３２に
示される文字列パターンと一致する文字列を有するファ
イルオブジェクトは、更新対象リストから取除かれる。

【０３０８】

【表３２】

【０３０９】ところで、step３で標準出力に出力された
情報は、複数回にわたるプリフェッチアクセスの記録で
あるから、同じファイルオブジェクト名称が何度も出現
する場合がある。そこで、このリストをさらに出現頻度
の降順にソートする。このとき同時に、同じURL につい
ては重複しないよう１つにまとめる。UNIX OS では、こ
のようなソート作業は標準的に提供されている次のコマ
ンド群を使って行なうことができる。

【０３１０】

【表３３】

【０３１１】そこで、次のコマンドにより上述のソート
作業を行なう。

【０３１２】

【表３４】

【０３１３】このコマンドの処理内容は次のとおりであ
る。まずfgrep -v -f exclude.txtでは、"exclude.txt"
ファイルに含まれる文字列パターンと一致しないファ
イルオブジェクトだけが標準出力に出力される。さらに
これをsortの標準入力とすることで、ファイルオブジェ
クト名称をアルファベット順に並べる。なおこの例で
は、単純に、URL が完全一致すべき文字列パターンのみ
を"exclude.txt" ファイルで指定しているが、以下に示
すように、URL が部分一致するべき文字列パターンを除
外するための"exclude.txt" ファイルを用意することも
考えられる。

【０３１４】

【表３５】

【０３１５】この例では、”＊”は任意の文字列パター
ンを示している。そのため以下に示すURL も、除外対象
となる。

【０３１６】

【表３６】

【０３１７】文字列パターンが部分一致するものを除外
するためには、表３４に示したコマンドをそのまま利用
することはできない。しかし、UNIX OS に標準で用意さ
れているコマンド群やＣ言語で記述したプログラム等の
組合せによってこれを容易に実現することが可能であ
る。

【０３１８】ここでは、表３２に示す内容が"exclude.t
xt" ファイルに格納されており、表３４に記載された処
理コマンドが処理に用いられたとして以下説明を進め
る。step３の標準出力が以下のとおりであるものとす
る。

【０３１９】

【表３７】

【０３２０】fgrep -v -f exclude.txt の処理によ
り、"exclude.txt" ファイルに格納された除外パターン
リストに含まれる文字列パターンに一致する文字列を有
する第３行と第４行とが取除かれる。その結果次のよう
な標準出力が得られる。

【０３２１】

【表３８】

【０３２２】さらにこれをsortの標準入力に与え、ASCI
I コード順にソートするとその結果は次のようになる。

【０３２３】

【表３９】

【０３２４】さらにこの出力をuniq -c の標準入力に与
えると、同一ファイルオブジェクト名称の行が集約さ
れ、出現頻度が第１フィールドに挿入されて出力され
る。その出力はこのようになる。

【０３２５】

【表４０】

【０３２６】得られたリストの各行の第１フィールド
は、出現頻度の数値と考えることができる。そこでこの
出現頻度の大きいものから順にソートするために、表４
０の内容をsort -n -rの標準入力に与えてソートするこ
とにより、このリストを出現頻度順に並べ変えることが
できる。その結果は次のようになる。

【０３２７】

【表４１】

【０３２８】step５次に第１のproxy プロセスのアクセスログファイルをｎ
日分収集する。この収集方法の具体的な手順は次のとお
りである。第１のproxy プロセスのアクセスログファイ
ル名称は、毎日名称が変わるように第１のproxy により
設定できる。たとえばログファイル名称の末尾に日付が
入るようにすると、第１のproxy プロセスのアクセスロ
グファイル名称は"/usr/local/etc/delegated/10000.ht
tp. 日"という名称にして毎日変わるようにすることが
できる。

【０３２９】そうするとたとえば、７月１日から７月１
０日までのログファイルの名称が次のとおりになる。

【０３３０】

【表４２】

【０３３１】このファイルの名称リストを、日付の新し
いものから順に並べる。そのためには、UNIX OS の下で
は、/bin/ls コマンドを-tオプションで起動すればよ
い。

【０３３２】

【数７】

【０３３３】これにより次の結果が得られる。

【０３３４】

【表４３】

【０３３５】さらにこれらのファイルリストから最近の
７日分のログファイル名称を抽出する。そのためには、
UNIX OS に標準的に搭載されている/usr/ucb/head コマ
ンドを用いて先頭の７行を抽出すればよい。headコマン
ドは、標準入力に与えられるリストから、先頭の指定行
数を抽出して標準出力に出力するものである。

【０３３６】

【数８】

【０３３７】この結果は次のとおりである。

【０３３８】

【表４４】

【０３３９】step６ここで、step５で収集した第１のproxy プロセスのアク
セスログファイルを、１つのファイル"workfile.txt"に
まとめる。このときに、各ファイルオブジェクトが最後
にユーザ中継された時刻と、プリフェッチが行なわれる
時刻との間隔に応じた重み付けを各ファイルオブジェク
トに与える。たとえば、単純にログファイルの日付に注
目すると、表４３には、新しい日付のログファイルから
順番に並んでいることがわかる。そこで、UNIX OS に標
準的に搭載されているcat コマンドを利用して次の処理
を行なう。

【０３４０】

【表４５】

【０３４１】こうすれば、プリフェッチを行なう当日に
残されたアクセスログは７回分として、前日に残された
アクセスログは６回分として、２日前に残されたアクセ
スログは５回分として、というように、最近にアクセス
されたファイルオブジェクトの出現頻度がより高くなる
ようなアクセスログリストが残される。

【０３４２】step７ step６で収集された"workfile.txt"ファイルは、１行ご
とに過去のアクセスファイルオブジェクトを記録したフ
ァイルである。そこでこの各行から、以下のような条件
でプリフェッチすべきファイルオブジェクト名称を含む
ものを選択する。

【０３４３】・httpコマンド文字列がファイルオブジェ
クトリード要求（ＧＥＴ）であり、かつ・ファイルオブジェクト名称のプロトコル部分がhttpで
あるもの・特定の文字列パターンにマッチするものを除外・ファイルオブジェクト名称がプリフェッチに適さない
ものを除外・ファイルオブジェクトのデータサイズが巨大なものを
除外・サーバ計算機の状態コードが特定のものを除外以上の条件を使い、"workfile.txt"ファイルからファイ
ルオブジェクト名称を抽出したリストを作成する。さら
に、作成されたリストの各行のファイルオブジェクト名
称のフィールドだけを取出し、プリフェッチすべきファ
イルオブジェクト名称のリストを標準出力に出力する。

【０３４４】ところで、ファイルオブジェクト名称がプ
リフェッチに適さないものとしては、たとえばURL 中
に”？”を含むものなとがある。これについては既に述
べたとおりである。

【０３４５】UNIX OS では、上に述べたようなファイル
オプション名称の抽出作業は、ＯＳとともに提供されて
いるコマンド群

【０３４６】

【表４６】

【０３４７】と、Ｃ言語などを用いて記述したプログラ
ム

【０３４８】

【表４７】

【０３４９】を使って行なうことができる。以下に、上
述の抽出処理を行なうコマンド例を示す。

【０３５０】

【表４８】

【０３５１】上のコマンドにより行なわれる処理の経過
を説明する。"workfile.txt"ファイルにあるログの形式
は既に述べたように表３１に示すとおりである。そこ
で、標準出力として得られる"workfile.txt"を"grep -
v" ＼?"に入力することで”？”を含まないようログを
抽出し、標準出力に出力する。それをさらに"grep"＼"G
ET" の標準入力に与えることで、コマンドがget コマン
ドである行のみが抽出され標準出力に出力される。

【０３５２】"grep"＼"GET" の標準出力をgrep＿datasi
ze DATASIZE の標準入力に与えると、ファイルオブジェ
クトのデータサイズが、予め指定しておいた定数DATASI
ZEより小さい行のみが抽出され標準出力に出力される。
標準出力をgrep＿response response.txt の標準入力に
与えると、サーバ計算機の状態コードが、予めファイ
ル"response.txt"に記述されている状態コードと一致す
る行のみが抽出され、標準出力に出力される。

【０３５３】さらに空白を区切りと考えると、各行の７
番目のフィールドがファイルオブジェクト名称に相当す
る。そこで、awk'｛print $7｝' を使用してファイルオ
ブジェクト名称部分のみを抽出する。さらにファイルオ
ブジェクト名称のプロトコル部分が"http"の行のみを抽
出するために"grep"＾http://"でフィルタリングしてい
る（" ＾" は行の先頭を示す。）。

【０３５４】step８ step７で標準出力に出力されたリストは、内部ネットワ
ークの複数のクライアント計算機からの、サーバ計算機
へのアクセスの記録である。したがってこのリスト中に
は同じファイルオブジェクト名称が何度も出現する場合
がある。

【０３５５】そこでこのURL リストを出現頻度順にソー
トし、かつ同じURL については重複しないように１つに
まとめる。また、step４同様、好ましくないファイルオ
ブジェクト名称を取除くため、ファイル"exclude.txt"
に格納された各行の文字列パターンと一致する文字列を
有する行を削除する。UNIX OS の下では、このようなソ
ート作業は、ＯＳとともに提供されている次のようなコ
マンド群を用いて行なうことができる。

【０３５６】

【表４９】

【０３５７】これらコマンド群を用いてたとえば次のよ
うなコマンドにより処理を行なう。

【０３５８】

【数９】

【０３５９】このコマンドは、前のステップの処理の標
準出力をsortの標準入力とすることにより、ファイルオ
ブジェクト名称をアルファベット順に並べる処理であ
る。

【０３６０】なお、ファイル"exclude.txt" に、ファイ
ルオブジェクト名称のうちURL が部分一致する文字列パ
ターンを格納し、この文字列パターンと部分一致するUR
L を有するファイルオブジェクト名称を除外することも
可能である。しかしここでは、ファイル"exclude.txt"
には、URL が完全一致すべき文字列パターンが格納され
ているものとする。

【０３６１】step７の標準出力の内容が次のとおりであ
るものとする。

【０３６２】

【表５０】

【０３６３】すると、”step７の標準出力｜sort”の結
果は、次のように表５０の各行がアルファベット順にソ
ートされたものとなる。

【０３６４】

【表５１】

【０３６５】さらにこの出力を"uniq -c" の標準入力に
与えると、同一ファイルオブジェクト名称を有する行が
集約され、かつ同一ファイルオブジェクト名称の行の出
現頻度が第１フィールドに挿入された次のようなリスト
が出力される。

【０３６６】

【表５２】

【０３６７】このリストの各行の第１フィールドは、対
応するURL の出現頻度を示す数値と考えことができる。
そこでこの第１フィールドを数値として扱って、降順に
ソートするためにsort -n -rの標準入力に与える。これ
により各行を出現頻度順に並べることができる。その結
果は次のようになる。

【０３６８】

【表５３】

【０３６９】すなわち、数８として記載したコマンドの
出力は"workfile2.txt" ファイルとなるが、このファイ
ル"workfile2.txt" は、出現頻度順に１行に１個のファ
イルオブジェクト名称がリストされたプリフェッチアク
セスリストとなる。

【０３７０】step９次に、step４の結果得られたファイ
ル"obsoletelist.txt"と、step８の結果得られたファイ
ル"workfile2.txt" とを連結して、１つのファイル"pre
fetch ＿url.txt"とする。その連結の順序は次のとおり
である。

【０３７１】（１）変更検出リスト"obsoletelist.tx
t" （２）プリフェッチアクセスリスト"workfile2.txt" この処理は、UNIX OS の下では具体的には次のコマンド
を用いて行なうことができる。

【０３７２】

【数１０】

【０３７３】step10 続いて、プリフェッチリストのインターリーブ処理を行
なう。このインターリーブ処理とは、実施の形態３で既
に説明した処理と同じものであり、プリフェッチアクセ
スリストを、その元々の順序そのものではなく、特定の
サーバにアクセスが集中しないような順序に並べ変える
処理をいう。こうすることにより、特定のサーバ計算機
にアクセスが集中する可能性を最も低くすることができ
る。その詳細は既に実施の形態３で説明してあるので、
ここでは繰返さない。

【０３７４】step11 続いて、並列ネットワーク中継個数の最大定数を計算す
る。すなわち、次のステップ以降に示すプリフェッチ子
プロセス起動ループで使用する、並列実行の子プロセス
数の許容される最大値である数MAXPROCESSを計算する。
これまで説明した実施の形態では、並行プリフェッチの
同時実行の最大値であるMAXPROCESSは、予め定められた
固定のパラメータであった。

【０３７５】すなわち、これまでの実施の形態では、プ
リフェッチプロセスの並列実行の子プロセスの数は次の
式によって規制されていた。

【０３７６】

【数１１】

【０３７７】このようにして、起動されるプリフェッチ
プロセスの並列実行の子プロセスの数を規制しておくこ
とで、他のプロセスに対するプリフェッチ子プロセスの
優先度が下がる、という効果があることはこれまでの実
施の形態の説明において既に述べたとおりである。なお
すべてのproxy ネットワーク中継プロセス数の中には、
プリフェッチ子プロセスが含まれている。

【０３７８】ところで、この場合次のような問題があ
る。たとえばMAXPROCESS＝２０と定められていたものと
する。この場合、次のステップのループ実行を始めた時
点で、クライアント計算機ユーザによるネットワーク中
継プロセスが２０個以上存在している場合がある。する
とそれだけで既に、上の数１１で示される条件が満たさ
れなくなる。すなわち、

【０３７９】

【数１２】

【０３８０】が成立せず、そのため新たにプリフェッチ
子プロセスを起動することができない。こうした状況が
連続すれば、実質的にプリフェッチを行なうことができ
ないという事態になる。本実施の形態は、こうした問題
を回避して、ネットワーク中継プロセスの数のかかわら
ず、着実にプリフェッチが行なえるように次のような方
策をとっている。すなわち、プリフェッチ子プロセスを
起動するか否かを判断するにあたって、「その時点での
すべてのproxy ネットワーク中継個数」に「一定数MAXP
ROCESS」を加えたものを新たなMAXPROCESSとして使用し
たうえで上の数１１の判断を行なっている。これによ
り、次のstep11以後のループを開始した時点ですべての
ネットワーク中継プロセスの合計数が初期定数MAXPROCE
SSを超えていても、上のようにして計算された新しい定
数MAXPROCESSが実際の比較の際には使用されるので、プ
リフェッチ用の並列子プロセスの新たな起動が可能とな
る。

【０３８１】以下具体的な実施方法について説明する。
まず、ある時点でのすべてのproxyによるネットワーク
中継個数をNUMPROCESSとする。NUMPROCESSは、ＯＳのプ
ロセステーブルから得ることができる。UNIX OS の下で
あれば次に挙げるコマンドの組合せでNUMPROCESSを計算
することができる。

【０３８２】

【表５４】

【０３８３】これらコマンドをたとえば次のように組合
せることでNUMPROCESSを得ることができる。

【０３８４】

【数１３】

【０３８５】ここでは、ネットワーク中継プロセス名称
が既に述べたように"DeleGate"であることを利用してい
る。さらに次の式によりMAXPROCESSを再計算する。

【０３８６】

【数１４】

【０３８７】これにより新たなMAXPROCESSを得ることが
できる。 step12 図９に示されるstep12.1とstep12.2とをここではまとめ
てstep12と呼ぶことにする。step12.1以降の処理は、st
ep10でインターリーブ化したプリフェッチリスト"prefe
tch ＿url.txt"の各行を１行ずつメモリ上の行バッファ
URLBUFに読込み、読込まれたURL に従ってプリフェッチ
子プロセスを起動するループ処理である。このとき、第
２のproxy を用い、当該ファイルオブジェクトをプリフ
ェッチするためのプリフェッチ子プロセスをバッググラ
ウンドプロセスとして１つ起動する。

【０３８８】なお、ネットワークアクセスをするために
は、プリフェッチ子プロセスから直接httpプロトコルを
発生させればよい。そのために専用のプログラムを作成
しておけばよい。このプログラムの名称を仮にwebacces
s とする。

【０３８９】プログラムwebaccess は、UNIX OS のネッ
トワーク機能の基本であるソケット機構を利用するもの
である。proxy プロセスのアドレスと、TCP/IPで使用さ
れるポート番号とを指定して、プロセス関数通信をする
ためのネットワーク接続を行なう。さらにMAXPROCESS
は、httpプロトコルにおけるGET コマンドを直接proxy
サーバに書込み、さらに応答データをメモリに読み捨て
る。読み捨てられた応答データは、proxy サーバのキャ
ッシュ機構により自動的にキャッシュファイル１６（図
９参照）に蓄積される。

【０３９０】webaccess を使用する場合の実際の記述例
は次のとおりである。

【０３９１】

【数１５】

【０３９２】この場合webaccess に対して、proxy サー
バのアドレスと、使用されるポート番号とが指定され
る。webaccess はこれに応答して上記記述中に含まれる
URL にアクセスしファイルを読出して内部のメモリに読
み捨てる。proxy プロセスが利用しているマシンのネッ
トワークアドレスがproxyserver 、TCP/IPのポート番号
が10001 番とする。行バッファURLBUFに次のファイルオ
ブジェクト名称が格納されているものとする。

【０３９３】

【数１６】

【０３９４】この場合次の命令によりwebaccess を起動
させれば、当該proxy プロセス経由で、サーバ計算機の
ファイルオブジェクト"http://www.xxx.co.jp/test/ind
ex.html"にアクセスできる。このとき中継子プロセスで
あるproxy 子プロセスができる。

【０３９５】

【数１７】

【０３９６】本実施の形態では、数１５により記述され
る、ファイルオブジェクト（URL ）についてのキャッシ
ュ更新アクセスにより、第１のproxy プロセスの管理す
るキャッシュファイル１６を最新状態に保つことができ
る。なお数１７で「＆」が末尾に付けられているのは、
子プロセスをバックグラウンドで並列に動作させるため
である。

【０３９７】step13 続いて図９のstep13で、プリフェッチ子プロセスの数と
第１のproxy プロセス１４のネットワーク中継子プロセ
スの数とを計測し加算して、変数processes に加える。
これらプロセス数も、step11で行なわれたのと同様、プ
ロセステーブルから得ることができる。

【０３９８】step14 続いてstep14で、上述のようにして得られた変数proces
ses が、step11で計算された最大プロセス数MAXPROCESS
以下か否かについて判定する。以下であれば制御はstep
2.1 に戻り、プリフェッチアクセスリストの次の１行を
抽出し、さらにバックグラウンドでプリフェッチ子プロ
セスを起動する。

【０３９９】step15 step14で、変数processes が最大プロセス数MAXPROCESS
よりも大きいと判定されると、処理を一定時間休止（た
とえば１０秒）する。この一定時間の休止を制御すると
制御をstep13に戻し、プリフェッチ子プロセスの並列起
動の起動を再び試みる。

【０４００】以上のようなループ処理によって、プリフ
ェッチ子プロセスの個数と、第１のproxy プロセス１４
を利用しているクライアント計算機ユーザのネットワー
ク中継子プロセスの個数との合計を制限しながら、プリ
フェッチ子プロセスの起動を制御する。この場合第１の
proxy プロセス１４を利用しているユーザによるネット
ワークアクセスの子プロセスの数がMAXPROCESS以上であ
ったときにプリフェッチ子プロセスが起動待ちとなる。

【０４０１】したがって、クライアント計算機のユーザ
が第１のproxy プロセス１４を利用している時間帯にプ
リフェッチプロセスを実行しても、プリフェッチ子プロ
セスには低い優先権しか与えられない。そのためプリフ
ェッチプロセスの始動を内部ユーザの活動時間帯に始め
ても内部ユーザのネットワーク利用の妨げとはならな
い。また逆にプリフェッチプロセスが、クライアント計
算機のユーザの活動時間の先頭部分に多少食い込んでも
内部ユーザのネットワーク利用にはそれほど支障がな
い。

【０４０２】したがって、プリフェッチプロセスの開始
から終了までより長時間のプリフェッチ処理を行なうこ
とが可能になる。より多くのファイルオブジェクトのプ
リフェッチができるので、キャッシュデータの量を増や
すことができる。結果としてキャッシュヒット率を高め
ることができる。これは、実施の形態１において既に述
べたのと同様に、平均ファイルオブジェクト転送速度を
増加させるという効果をもたらす。見方を変えれば、同
じ平均ファイルオブジェクト転送速度を維持しながら、
内部ネットワークのより多くのユーザがネットワーク利
用をできるようにするという効果がある。

【０４０３】なお、図９のstep15の後に、このプリフェ
ッチプロセスループを指定時刻に強制終了するためにＯ
Ｓタイマをセットする。ＯＳタイマは、UNIX OS に標準
的に提供されているコマンドを利用して、指定時間に指
定の動作を実行させることで実現できる。指定時刻に上
記したプロセスを終了するためには、具体的には次のよ
うにすればよい。図８および図９に示されるプリフェッ
チプロセスには、実行時にはプロセスＩＤ番号がシステ
ムから与えられる。そこでこのプロセスＩＤ番号を使用
して、UNIX OS のkill命令を次のようにＯＳに与える。

【０４０４】

【数１８】

【０４０５】このコマンドは、プロセスＩＤ番号で指定
されたプロセスを終了させるためのkill命令を、８時０
０分に発行するようにＯＳに対して予約するものであ
る。

【０４０６】以上は、プリフェッチプロセスの詳細な説
明である。次に、第１のproxy プロセス１４および第２
のproxy プロセス３４におけるキャッシュ管理手法につ
いて説明する。本発明では、２つのproxy プロセスが図
１、図９等に示すようにキャッシュファイル１６を共有
している。しかも両者ともキャッシュファイル１６を、
ファイルオブジェクト単位で更新する。そのためキャッ
シュファイル１６について、ファイルオブジェクト単位
で排他制御ができなければ、ネットワーク中継子プロセ
ス同士で競合が生じてしまう。そのためproxy プロセス
のキャッシュ管理手法が排他制御を備えている必要があ
る。

【０４０７】本願の実施の形態では、公知の"DeleGate"
と呼ばれるproxy ソフトウェアを使用している。このソ
フトウェアは排他制御機能を備えており、上述したよう
な本願発明の実施の形態を実現するに十分な機能を備え
ている。

【０４０８】DeleGateにおけるキャッシュ管理手法は、
ソースコードの形で公開されている。したがって以下こ
のソースコードに沿ってその手法について述べる。なお
本願発明を実現するためのproxy サーバソフトウェアと
しては、このDeleGateに限定されるものではなく、同様
のキャッシュ管理手法が使われるキャッシュ機能付prox
y サーバソフトウェアであって排他制御機能を有するも
のであれば利用することができる。

【０４０９】既に述べた例に従って、proxy プロセスが
proxyserver という名称のマシン（システム）で動作し
ており、TCP/IPのポート番号10001 番でURL 取得要求を
受付けるものとする。このとき、バッファURLBUFに、指
定のURL 表記が格納されているものとする。すると、た
とえば図９に示すプリフェッチプロセス４１は次のコマ
ンドを実行する。

【０４１０】

【数１９】

【０４１１】なお第２のproxy プロセス３４とプリフェ
ッチプロセス４１との間の通信はTCP/IPを用いて行なわ
れる。例としてバッファURLBUFに"http://www.sharp.c
o.jp/sample/test.html" という文字列が格納されてい
るものとする。

【０４１２】プリフェッチプロセス４１が数１４に示す
コマンドを実行することにより、URL 取得要求が第２の
proxy プロセス３４に出される。第２のproxy プロセス
３４はこれに応答して子プロセスを生成し、実際のファ
イルオブジェクトの取得処理をその子プロセスに任せ
て、自プロセスは再びプリフェッチプロセス４１による
数１４の実行を待ち受ける。第２のproxy プロセス３４
により生成された子プロセスは、以下のような処理を実
行する。なおproxy プロセスは、キャッシュファイルと
して図７に示すキャッシュファイル１６を持っている。
このキャッシュファイル１６は、通常のUNIXファイルシ
ステムの一部として作られる。この場合、キャッシュ用
ディレクトリとして/cacheというパーティションを使用
するものとする。このとき、バッファURLBUFに格納され
ている文字列のうち次の文字列

【０４１３】

【数２０】

【０４１４】は、プロトコル名称がhttp、サーバ計算機
名称がwww.sharp.co.jp 、ファイルオブジェクトの実体
部分のディレクトリおよびファイル名称はsample/text.
htmlである。このとき、キャッシュファイル１６は次の
名称規則に従ってキャッシュファイルを生成しようとす
る。

【０４１５】

【数２１】

【０４１６】したがって"http://www.sharp.co.jp/samp
le/test.html" のディレクトリおよびファイル名は次の
ようにして指定される。

【０４１７】

【数２２】

【０４１８】したがって、図１０を参照して、proxy プ
ロセスは次のようにキャッシュファイル１６の排他制御
を行なう。

【０４１９】（１）まずキャッシュファイル１６の更
新ルーチンを開始すると（Ａ１）、指定されたURL を上
記した規則に従ってキャッシュファイル名称に変換す
る。今述べている例では上述の数２２というファイル名
称が得られる（Ａ２）。そしてこのようにして変換され
たファイル名称がキャッシュファイル１６内に存在する
か否かを調べる。具体的には、ＯＳのopen（）システム
コールによって、このファイルを既存のファイルとして
オープンすることができるかどうかを調べることにより
このファイルの存在を調べる（Ａ３）。

【０４２０】（２）このファイルが存在しなければ
（Ａ３でＮＯ）、このキャッシュファイルをファイル新
規作成モードでオープンする（Ａ４）。

【０４２１】（３）さらにこのキャッシュファイルに
対して他のプロセスから書込が行なえないように排他ロ
ックする（Ａ５）。これ以後の処理が排他制御である。

【０４２２】（４）次にネットワーク経由で、バッフ
ァURLBUF内の文字列で指定されたファイルオブジェクト
を、指定されたサーバ計算機から取得する（Ａ６）。

【０４２３】（５）このようにして取得したファイル
オブジェクトをキャッシュ更新プロセスに渡すととも
に、キャッシュファイル１６に書込む（Ａ７）。このと
きのキャッシュファイル名称は数２２に示したとおりで
ある。

【０４２４】（６）書込が完了するとキャッシュファ
イルをクローズして排他ロックを解除する（Ａ８）。

【０４２５】ステップＡ３でキャッシュファイルがオー
プンできた場合、すなわち指定されたキャッシュファイ
ルが既に存在した場合には次のような処理を行なう（Ａ
９）。

【０４２６】（７）キャッシュファイル/cache/http/
www.sharp.co.jp/sample/test.htmlの最終変更時刻Tmを
ＯＳから得る。UNIXであれば、最終変更時刻はfstat
（）システムコールで得られる（Ａ１０）。fstat
（）システムコールは、過去から未来に向かって時間
の経過とともに単純に増加する関数である。

【０４２７】（８）続いて現在時刻をシステムコール
を用いて読出しTnowという変数に格納する（Ａ１１）。

【０４２８】（９）上記したキャッシュファイルの最
終変更時刻Tmと現在時刻Tnowとを比較し、その差がキャ
ッシュ有効期限以内かどうかを判定する（Ａ１２）。

【０４２９】（１０）キャッシュ有効期限以内であれ
ば（Ａ１２においてＹＥＳ）、このキャッシュファイル
を共有排他ロックする。すなわちこのキャッシュファイ
ルに対して、他のプロセスからの書込はできないが、読
出はできるようにする（Ａ１３）。

【０４３０】（１１）続いて現在のキャッシュファイ
ルを読出し、キャッシュ更新プロセスに転送する（Ａ１
４）。

【０４３１】（１２）キャッシュファイルをクローズ
し、排他制御のロックを解除する（Ａ８）。

【０４３２】一方、キャッシュ有効期限を過ぎている場
合（Ａ１２においてＮＯ）、次のような処理を行なう。

【０４３３】（１３）キャッシュファイルを排他ロッ
クし、他のプロセスからの書込が行なわれないようにす
る（Ａ１５）。

【０４３４】（１４）次にネットワーク経由で、バッ
ファURLBUFに格納された文字列で指定されたファイルオ
ブジェクトをサーバ計算機から取得する（Ａ１６）。

【０４３５】（１５）こうして取得したファイルオブ
ジェクトをキャッシュ更新プロセスに渡すとともに、数
２２で示されるキャッシュファイルに書込む（Ａ１
７）。

【０４３６】（１６）続いてキャッシュファイルをク
ローズし排他ロックを解除する（Ａ１８）。

【０４３７】以上が、上述の実施の形態で使用されてい
るproxy プロセスのキャッシュ制御手順である。本願発
明の各実施の形態では、このようなproxy プロセスによ
る排他制御機能を利用して、キャッシュファイルシステ
ム（たとえば図７のキャッシュファイル１６）を、第１
のproxy プロセス１４と第２のproxy プロセス３４とで
共有している。なお第２のproxy プロセス３４は、既に
述べたようにキャッシュ有効期限＝０である。またキャ
ッシュファイルの最終変更時刻Tmは常に現在時刻Tnowよ
りも小さい。したがって、図１０のステップＡ１２で行
なわれる判断は、第２のproxy プロセス３４経由のサー
バ計算機アクセスでは必ずＮＯという結果になり、キャ
ッシュファイルの更新（Ａ１６）が必ず行なわれる。

【０４３８】以上のようにこの実施の形態でも、ファイ
ルオブジェクト（URL ）のプリフェッチにより、第１の
proxy プロセス１４の管理するキャッシュファイル１６
の容量をｎ×２４時間／ｍ倍に増やし、かつ最新状態に
保つことが可能である。

【０４３９】なお本実施の形態のstep５でｎ日分の過去
のアクセスログファイルを集めたが、このｎ日という数
字は、キャッシュファイルの最大容量とファイル転送実
績とから決められるものであって、システムごとに異な
る。１ＧＢの容量を持つキャッシュファイル装置に、１
日当り１００ＭＢのファイルオブジェクトが蓄積される
ようであれば、ｎ＝５程度、すなわちファイルオブジェ
クトが５００ＭＢ程度プリフェッチされるような設定と
すれば、キャッシュファイル１６が溢れることはない。

【０４４０】このようにキャッシュファイルの蓄積の実
績から、キャッシュファイルを溢れさせないｎという数
字を算出するのは容易である。そのためには次のように
する。たとえば１ＧＢの容量を有するキャッシュファイ
ル装置であれば、キャッシュ蓄積量の最小値ＭＩＮ＝６
０％、最大値ＭＡＸ＝８０％と定めておく。キャッシュ
蓄積の実績量がＭＩＮを下回るようであれば、毎日のプ
リフェッチ起動時にｎ＝ｎ＋１とする。またキャッシュ
蓄積の実績量がＭＡＸを上回る場合には、ｎ＝ｎ−２な
どと減らす。こうすることでキャッシュ蓄積容量をほぼ
ＭＩＮ、ＭＡＸの間に保つことができる。

【０４４１】このようなプリフェッチプロセスは、内部
ネットワークから外部ネットワークへのクライアント計
算機ユーザのアクセスがあまりない時間帯を利用して起
動することができる。そうすることによってプリフェッ
チプロセスによるファイルオブジェクトアクセスが、内
部ネットワークユーザの外部ネットワークアクセスの妨
げにならないような運用をすることができる。上述の実
施の形態では、プリフェッチプロセスはクライアント計
算機の利用が少なくなる２１時００分に起動し、翌日の
８時００分には遅くとも終了させるようにしてある。８
時００分にプリフェッチプロセスがまだ動作しているの
であれば既に述べたように強制終了をさせている。これ
により、プリフェッチリストが大きくて、プリフェッチ
に時間を要し、そのため翌日の８時までにプリフェッチ
プロセスが終了しない場合であっても、クライアント計
算機の利用が始められる時間帯にはプリフェッチプロセ
スが確実に終了される。これ以後の、内部ネットワーク
ユーザによるクライアント計算機の利用は妨げられな
い。

【０４４２】ところで、上述の実施の形態でも、第１の
proxy プロセス１４のキャッシュ有効期限Ｍ＝２４時間
としている。そのため夜間に更新されたキャッシュデー
タの内容は、更新後翌晩の２１時までは少なくとも有効
である。すなわち、キャッシュファイルのうち少なくと
も変更頻度の高いファイルオブジェクトは過去２４時間
以内に更新された情報に維持される。一方で、キャッシ
ュファイルの容量は１日の平均アクセス量のｎ日分であ
る。キャッシュヒット率は、キャッシュの蓄積期間が２
４時間の場合と比較してｎ＝７とすると３倍以上となる
ことが経験的にわかっているから、上述のような設定を
することでキャッシュファイルの内容を新鮮に保ちなが
らキャッシュヒット率を高めることができる。また、第
１のproxy プロセス１４のキャッシュ有効期限Ｍ時間以
下の時間間隔でプリフェッチプロセスの起動が行なわれ
るから、キャッシュファイルは常に有効期限内に保たれ
る。したがってプリフェッチから次のプリフェッチまで
の間、プリフェッチの効果が有効に保たれる。

【０４４３】［実施の形態７］実施の形態１〜６では、
ゲートウェイ計算機とクライアント計算機とが別々の計
算機であるものとして説明した。しかしながら、図１１
に示されるように、ゲートウェイ計算機５５の中にクラ
イアントプロセス４２を起動して、クライアント計算機
の機能を含ませても何ら問題はない。その逆にクライア
ント計算機の中にゲートウェイ計算機の機能を含ませて
も支障がないことはもちろんである。なお図１１におい
て図７に示される各構成要素と同じ構成要素には同一の
参照番号および名称を付してある。それらの機能も同一
である。したがってここではそれらについての詳しい説
明は繰返さない。

【０４４４】このようにクライアント計算機とゲートウ
ェイ計算機との機能を同一の計算機内に組込むことによ
り、より多くのファイルオブジェクトのプリフェッチを
することが可能になる。そのためキャッシュデータの量
を増やすことができるので、結果としてキャッシュヒッ
ト率を高めることができる。ゲートウェイ計算機として
得られる効果は、既に述べた他の実施の形態の装置によ
り得られるものと同様である。

【０４４５】再びここで各実施の形態の効果について述
べる。実施の形態１によれば、内部ネットワークユーザ
が利用するproxy プロセスでは、キャッシュ有効期限Ｍ
がたとえば２４時間というように短く設定されている。
したがってキャッシュされたファイルオブジェクトの内
容は、最近の２４時間以内の内容であることが保証され
ている。すなわちキャッシュファイルのステールデータ
率は小さく抑えられている。一方、キャッシュファイル
自体にはｎ日分のキャッシュファイルが蓄積さている。
キャッシュの蓄積量が、プリフェッチプロセスを行なわ
ない場合と比較してｎ×２４／Ｍ倍となるので、キャッ
シュのヒット率はキャッシュ有効期限をｎ日としたとき
に相当する高い値となる。

【０４４６】従来のproxy サーバ装置で、キャッシュ有
効期限を２４時間と設定した場合のキャッシュヒット率
は１２％程度であることが観察されている。一方実施の
形態１のproxy サーバ装置によるプリフェッチ処理を実
行した場合、ｎ＝７日とすると、上述のようにキャッシ
ュヒット率が高くなることが予測され、実際にもヒット
率は３５％となった。このためweb サーバへの問合せが
減少し、応答速度が向上した。

【０４４７】実施の形態２のproxy サーバ装置では、プ
リフェッチを同時並列的に進めることで、プリフェッチ
の開始から終了までの時間を短縮することができる。指
定終了時刻までの間に、より多くのファイルオブジェク
トをプリフェッチできる。キャッシュデータの量を増や
すことができるので、結果としてキャッシュヒット率を
高めることができる。

【０４４８】実施の形態３のproxy サーバ装置では、プ
リフェッチアクセスリスト内のファイルオブジェクト名
称をインターリーブしてからプリフェッチを同時並行的
に進める。そのため特定のサーバ計算機に対してアクセ
スが集中することが避けられる。サーバ計算機の応答が
遅くなってボトルネックとなることが避けられるので、
プリフェッチの開始から終了までの時間を短縮できる。
指定終了時刻までの間により多くのファイルオブジェク
トのプリフェッチが可能になる。キャッシュデータの量
を増やすことができるので、結果としてキャッシュヒッ
ト率を高めることができる。

【０４４９】実施の形態４によれば、内部のユーザが第
１のproxy プロセスを利用している時間帯にプリフェッ
チプロセスを実行しても、プリフェッチ子プロセスには
低い優先権しか与えられていないので、内部ユーザのネ
ットワーク利用活動を妨げることがないという効果があ
る。プリフェッチプロセスを、内部ユーザの活動時間帯
内に始めても、内部ユーザのネットワーク利用の妨げと
はならない。またプリフェッチプロセスの終了を、内部
ユーザの活動時間帯内までずれ込ませても内部ユーザの
ネットワーク利用の妨げとはならない。開始から終了ま
でより長時間のプリフェッチ時間を利用することが可能
になり、より多くのファイルオブジェクトをプリフェッ
チすることができる。キャッシュデータの量も応じて増
加できるので、結果としてキャッシュヒット率を高める
ことができる。

【０４５０】実施の形態５のproxy サーバ装置では、キ
ャッシュファイル中のファイルオブジェクトを消去する
ための期限はｎ日程度としている。この期限は、キャッ
シュファイルの有効期限よりも長く選択されており、有
効期限が過ぎたキャッシュファイルも直ちには消去され
ない。そして有効期限が過ぎたファイルオブジェクトで
あっても、アクセス要求が生じ該当するサーバ計算機の
元データの変更時刻を照会することにより、サーバ計算
機の元データが変更されていなければ再びこのキャッシ
ュされているファイルオブジェクトが有効となる。そし
てこのファイルオブジェクトのヘッダ情報の変更時刻を
更新するだけで、実際のファイルオブジェクトのデータ
転送をすることなく実質的にファイルオブジェクトのプ
リフェッチを実現できる。そのため再ロードのためのト
ラフィックを削減することができる。

【０４５１】プリフェッチによるキャッシュのヒット率
向上により、昼間のユーザの活動によるファイルオブジ
ェクト転送量は十分減少しており、上述のプリフェッチ
を行なってもトラフィックがいたずらに増大するおそれ
はない。またキャッシュファイルの内容は、いずれも有
効期限内に維持できるので、その内容の新鮮さを維持す
ることができる。

【０４５２】実施の形態６では、第２のproxy のログフ
ァイル中で変更があったことを示す行のみが抽出され、
第１のproxy のログファイルから抽出されたプリフェッ
チリストの先頭にマージされる。一般に、前回のプリフ
ェッチ時に変更があったファイルオブジェクトは、変更
頻度が高いということができる。したがってこれらを優
先してプリフェッチすることで、限られた時間を有効に
利用して、キャッシュファイルの状態を最新の状態に近
く維持するとが可能になる。

【０４５３】上述した実施の形態のいずれも、既存のpr
oxy プロセスにさらにプリフェッチプロセスを追加する
だけで実現でき、既存のproxy プロセス自体には何らの
変更も必要ではない。そのため容易にキャッシュファイ
ルのヒット率が向上したproxy サーバ装置を提供できる
という利点がある。なお、ＨＴＴＰプロトコルを含めた
参考文献リストを以下に示す。

【０４５４】

【表５５】

【図面の簡単な説明】

【図１】本発明に係るゲートウェイ装置の一例であるpr
oxy サーバ装置の動作概念図である。

【図２】ＷＷＷサーバ内の情報頁をクライアントソフト
ウェアでブラウズしたときの表示画面を示す図である。

【図３】実施の形態１のゲートウェイ装置であるproxy
サーバ装置で行なわれるプリフェッチプロセスの実現ア
ルゴリズムを示すフローチャートである。

【図４】実施の形態２のゲートウェイ装置であるproxy
サーバ装置で行なわれるプリフェッチプロセスの実現ア
ルゴリズムを示すフローチャートである。

【図５】実施の形態３のゲートウェイ装置であるproxy
サーバ装置で行なわれるプリフェッチプロセスの実現ア
ルゴリズムを示すフローチャートである。

【図６】実施の形態４のゲートウェイ装置であるproxy
サーバ装置で行なわれるプリフェッチプロセスの実現ア
ルゴリズムを示すフローチャートである。

【図７】本発明の実施の形態６に係るproxy サーバ装置
のブロック図である。

【図８】実施の形態６のproxy サーバ装置におけるプリ
フェッチプロセスの前半部のフローチャートである。

【図９】実施の形態６のproxy サーバ装置におけるプリ
フェッチプロセスの後半部のフローチャートである。

【図１０】実施の形態６のproxy サーバ装置でのキャッ
シュファイル更新子プロセスのフローチャートである。

【図１１】本願発明の実施の形態７のproxy サーバ装置
のブロック図である。

【図１２】従来のゲートウェイ計算機の構成を示す図で
ある。

【図１３】proxy サーバ装置の概念図である。

【図１４】proxy サーバ装置の回路構成の第１の例を示
す図である。

【図１５】proxy サーバ装置の回路構成の第２の例を示
す図である。

【図１６】proxy サーバ装置の回路構成の第３の例であ
って、本願発明の実施の形態proxy サーバ装置としても
使用されるproxy サーバ装置の回路構成を示す図であ
る。

【図１７】キャッシュヒット率と平均アクセス速度との
関係を示すグラフである。

【図１８】キャッシュファイルサイズとキャッシュヒッ
ト率との関係を示すグラフである。

【図１９】キャッシュ有効期限とキャッシュファイルの
大きさとの関係を示すグラフである。

【符号の説明】

１１サーバ計算機１４第１proxy プロセス１５アクセスログ１６キャッシュファイル３０アクセスリスト３４第２のproxy プロセス３６プリフェッチプロセス

Claims

【特許請求の範囲】

【請求項１】クライアント計算機が存在する第１のネ
ットワークと、サーバ計算機が存在する第２のネットワ
ークとの間に介在するように設けられるゲートウェイ装
置であって、第１のネットワークのクライアント計算機からのファイ
ルオブジェクトに対するアクセス要求に応答して、当該
ファイルオブジェクトにより指定されるサーバ計算機に
対して、当該ファイルオブジェクトに対するアクセス要
求を行なう第１のネットワークファイル中継手段を含
み、前記第１のネットワークファイル中継手段は、取得したファイルオブジェクトを、所定の有効期限が経
過するまで一時的に蓄積するとともに、最終変更時刻を
ファイルオブジェクト単位で記録するためのキャッシュ
ファイル手段と、過去の、一定期間内に行なわれたファイルオブジェクト
の転送記録を蓄積するファイル転送記録手段と、ファイルオブジェクトに対するアクセス要求に応答し
て、当該ファイルオブジェクトの最終変更時刻を参照
し、有効期限内のファイルオブジェクトが前記キャッシ
ュファイル手段に存在するか否かを判断し、当該判断結
果に基づいて、当該ファイルオブジェクトを前記キャッ
シュファイル手段、または当該ファイルオブジェクトに
より指定されるサーバ計算機から取得してクライアント
計算機に転送するための転送手段とを含み、前記ゲートウェイ装置はさらに、予め定められたスケジ
ュールに従って、前記転送記録中のファイルオブジェク
トをサーバ計算機からプリフェッチして、前記キャッシ
ュファイル手段に格納するための第２のネットワークフ
ァイル中継手段を含む、ゲートウェイ装置。
【請求項２】前記第２のネットワークファイル中継手
段は、前記第２のネットワークを介して同時に複数個の
ファイルオブジェクトをサーバ計算機から同時並列的に
プリフェッチする、請求項１記載のゲートウェイ装置。
【請求項３】前記第２のネットワークファイル中継手
段は、同一のサーバ計算機からのプリフェッチの同時発
生を回避するように、ファイルオブジェクトのプリフェ
ッチの順序を決定する、請求項２記載のゲートウェイ装
置。
【請求項４】前記第２のネットワークファイル中継手
段は、前記転送記録からファイルオブジェクトのリスト
を当該転送記録中の出現頻度に従って抽出し、当該リス
ト中のファイルオブジェクトの順序に従ってファイルオ
ブジェクトのプリフェッチを同時並列的に行なう、請求
項２記載のゲートウェイ装置。
【請求項５】前記第２のネットワークファイル中継手
段は、前記リスト中のファイルオブジェクトの順序を入
替え、当該入替られた順序に従ってファイルオブジェク
トのプリフェッチを同時並列的に行なう、請求項４記載
のゲートウェイ装置。
【請求項６】前記第２のネットワークファイル中継手
段は、前記リストを複数個のブロックに区分し、各ブロ
ックごとにファイルオブジェクトの順序を入替え、当該
順序が入替えられたリスト上での順序に従ってファイル
オブジェクトのプリフェッチを同時並列的に行なう、請
求項５記載のゲートウェイ装置。
【請求項７】前記第１のネットワークファイル中継手
段は、各々が第１のネットワークのクライアント計算機
からのファイルオブジェクトのアクセス要求を処理する
ための第１の転送プロセスを複数個、同時並列的に起動
させることが可能であり、前記第２のネットワークファイル中継手段は、各々が１
つの前記ファイルオブジェクトのプリフェッチを行なう
ための第２の転送プロセスを複数個、同時並列的に起動
させることが可能であり、かつ前記第１の転送プロセス
の数を検知して、前記第１の転送プロセスの数と、前記
第２の転送プロセスの数との和が予め定められる上限以
下となるように前記第２の転送プロセスの新たな起動を
制御する、請求項２から６のいずれかに記載のゲートウ
ェイ装置。
【請求項８】前記第２のネットワークファイル中継手
段は、予め定められた時間帯でのみファイルオブジェク
トのプリフェッチを行なう、請求項１から７のいずれか
に記載のゲートウェイ装置。
【請求項９】前記第２のネットワークファイル中継手
段は、前記第１のネットワークファイル中継手段の前記
キャッシュファイルの有効期限以下の周期で定期的にフ
ァイルオブジェクトのプリフェッチを行なう、請求項１
から８のいずれかに記載のゲートウェイ装置。
【請求項１０】前記第１のネットワークファイル中継
手段の前記キャッシュファイル手段は、前記有効期限以
上の所定の消去時間が経過するまでは、当該キャッシュ
ファイル手段に格納されているファイルオブジェクトを
消去せず、前記転送手段は、前記有効期限が経過しているが消去は
されていないファイルオブジェクトに対するアクセス要
求に応答して、対応するサーバ計算機にアクセスし、当
該サーバ計算機内の当該ファイルオブジェクトが、前回
の取得後更新されているか否かを判断し、更新されてい
ないときには前記キャッシュファイル手段内のファイル
オブジェクトを新たに取得したファイルオブジェクトと
してクライアント計算機に転送し、更新されているとき
には当該ファイルオブジェクトにより特定されるサーバ
計算機に対して当該ファイルオブジェクトの転送要求を
発して更新後の当該ファイルオブジェクトを取得し、取
得したファイルオブジェクトをクライアント計算機に転
送する、請求項１記載のゲートウェイ装置。
【請求項１１】前記第１のネットワークファイル中継
手段は、各々が第１のネットワークのクライアント計算
機からのファイルオブジェクトのアクセス要求を処理す
るための第１の転送プロセスを複数個、同時並列的に起
動させることが可能であり、前記第２のネットワークファイル中継手段は、各々が１
つの前記ファイルオブジェクトのプリフェッチを行なう
ための第２の転送プロセスを複数個、同時並列的に起動
させることが可能であり、前記第２の転送プロセスの起
動時において既に稼動中の転送プロセスの数を検知し
て、前記稼動中の転送プロセスの数と、起動すべき第２
の転送プロセスの数との和が、前記稼動中の転送プロセ
スの数と予め定める定数との和以下となるように前記第
２の転送プロセスの新たな起動を制御する、請求項２か
ら６のいずれかに記載のゲートウェイ装置。
【請求項１２】前記第２のネットワークファイル中継
手段は、過去の一定期間中に行なったファイルオブジェ
クトの転送記録を、転送時に当該ファイルオブジェクト
の変更が検出されたか否かを示す情報とともに蓄積する
ための第２のファイル転送記録手段をさらに含み、前記第２のネットワークファイル中継手段は、前記第２
のファイル転送記録手段により記録された前記転送記録
中から、直前のフェッチ時において変更が検出されたフ
ァイルオブジェクトを抽出し、これらのファイルオブジ
ェクトを、前記ファイル転送記録手段の転送記録中のフ
ァイルオブジェクトよりも優先的にサーバ計算機からプ
リフェッチして前記キャッシュファイル手段に格納す
る、請求項１に記載のゲートウェイ装置。
【請求項１３】前記第２のネットワークファイル中継
手段は、予め指定された文字列パターンを記憶し、前記
第２のファイル転送記録手段により記録された前記転送
記録中から、前記予め定められた文字列パターンと一致
する文字列を有するファイルオブジェクトを排除して抽
出する、請求項１０に記載のゲートウェイ装置。
【請求項１４】前記第２のファイル転送記録手段の蓄
積する転送記録は、取得されたファイルオブジェクトの
ファイルサイズをさらに含み、前記第２のネットワークファイル中継手段は、転送対象
となるファイルオブジェクトサイズの最大値を特定する
情報を予め記憶し、前記第２のファイル転送記録手段に
より記録された前記転送記録中から、前記最大値より大
きなファイルサイズを有するファイルオブジェクトを排
除して抽出する、請求項１０に記載のゲートウェイ装
置。
【請求項１５】前記第２のファイル転送記録手段の蓄
積する転送記録は、取得が試行されたファイルオブジェ
クトに関するサーバ計算機の状態コードをさらに含み、前記第２のネットワークファイル中継手段は、サーバ計
算機の特定の状態コードを予め記憶し、前記第２のファ
イル転送記録手段により記録された前記転送記録中か
ら、前記特定の状態コードと一致する状態コードを有す
るファイルオブジェクトを排除して抽出する、請求項１
０に記載のゲートウェイ装置。
【請求項１６】前記第１のネットワークファイル中継
手段に対するクライアント計算機としての機能を実現す
るための手段をさらに含む、請求項１から１５のいずれ
かに記載のゲートウェイ装置。