JP3748195B2 - Network cache device and network cache control method - Google Patents
Network cache device and network cache control method Download PDFInfo
- Publication number
- JP3748195B2 JP3748195B2 JP2000145399A JP2000145399A JP3748195B2 JP 3748195 B2 JP3748195 B2 JP 3748195B2 JP 2000145399 A JP2000145399 A JP 2000145399A JP 2000145399 A JP2000145399 A JP 2000145399A JP 3748195 B2 JP3748195 B2 JP 3748195B2
- Authority
- JP
- Japan
- Prior art keywords
- file
- storage unit
- management table
- server
- requested
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、ファイルを保管し提供するサーバーとファイルを利用する端末をつなぐネットワーク上に配置、または該端末に具備されるネットワークキャッシュ装置およびネットワークキャッシュ制御手法に関する。
【０００２】
【従来の技術】
ネットワーク内に配置するキャッシュまたはネットワークに接続されたクライアント端末に具備されたキャッシュにおいて、新しくサーバーから送信されてきたファイルをキャッシュする際に、キャッシュ内に十分なスペースがない場合、どのファイルから削除するか判断する手段が必要である。この際、キャッシュでフォルトしたデータ量（フォルトしたファイルのサイズの和）を少なくするためには、参照頻度の高いファイルをキャッシュに残し、参照頻度の低いファイルを削除するようなキャッシュ制御手法が望ましい。
【０００３】
キャッシュ制御手法として、最も参照時刻の古いページから順に削除するＬＲＵ（Ｌｅａｓｔ Ｒｅｃｅｎｔｌｙ Ｕｓｅｄ）と呼ばれる方法が一般的である。これは、もともと仮想記憶システムにおけるページング手法として考案されたものである。一般に、プログラムは、最近アクセスしたページにアクセスしやすいという局所参照性を持っている。ＬＲＵは、この局所参照性を利用することにより、参照頻度の低いファイルを削除する。
【０００４】
端末で起動される、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）のブラウザなどのアプリケーションから出される、ファイルへのリクエストもこの局所参照性をもっているため、ＬＲＵ法はネットワークにおけるキャッシングでも有効であると考えられている。
【０００５】
参照時刻だけでなくサイズに着目した場合、ＷＷＷのトラヒックの場合のように、小さいファイルの方が頻繁にアクセスされる傾向がある場合がある。このような場合、ＬＲＵ方式よりも、大きいファイルから優先して削除するＳｉｚｅ方式が、ＬＲＵよりもさらに有効である（参考文献：Ｓ．Ｗｉｌｌｉａｍｓ ａｎｄ Ｍ．Ａｂｒａｍｓ ａｎｄ Ｃ．Ｒ．Ｓｔｒａｎｄｒｉｄｇｅ ａｎｄ Ｇ．Ａｂｄｕｌｌａ ａｎｄ Ｅ．Ａ．Ｆｏｘ，“Ｒｅｍｏｖａｌ Ｐｏｌｉｃｉｅｓ ｉｎ Ｎｅｔｗｏｒｋ Ｃａｃｈｅｓ ｆｏｒ Ｗｏｒｌｄ−Ｗｉｄｅ−Ｗｅｂ Ｄｏｃｕｍｅｎｔｓ”，Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＳＩＧＣＯＭＭ，ＡＣＭ，１９９６）。これは、ＬＲＵ方式が、一度キャッシュに入ったファイルは、それが滅多に参照されてないものであっても、参照時刻がキャッシュの中で最も古くなるまで、削除されないのに対し、Ｓｉｚｅ方式は、キャッシュされているファイルの中でもっとも大きければ、即座に削除されるためである。また、画像ファイルやテキストファイルなどファイルの属性に参照頻度が予測できる場合は、参照頻度が高い属性を持つファイルに対して高い優先度を与えられ、Ｓｉｚｅ方式と同様な効果が得られる。
【０００６】
しかし、上記のようにリクエストされるファイルのサイズや属性の分布を仮定したキャッシュ制御方式では、参照頻度を考慮にいれていないため、何かの影響でその仮定が崩れた場合や、仮定があてはまらなかった場合に、極端にフォルトするデータ量が多くなる場合がある。例えば、Ｓｉｚｅ方式を採用していた場合、キャッシュされているどのファイルよりも大きいファイルへのリクエストが連続した場合、キャッシュに入ったばかりのファイルがすぐ削除され、フォルトしたデータ量が極端に大きくなるという問題があった。
【０００７】
特開平７−１８２２２０号公報は、キャッシュされるファイルを、優先度の低い順にファイルを削除する第１のグループと、ＬＲＵでファイルを削除する第２のグループにわける。新しいオブジェクトをキャッシュするために、すでにキャッシュされているファイルを削除する際には、二つのグループから一つを適宜選択して、削除する。しかし、グループの選択の仕方によっては、フォルト量が極端に多くなるという問題がある。
【０００８】
特開平１１−６５９２７号公報は、キャッシュ制御方式の異なる複数のストレージを持つ方法である。しかし、これは独立した複数のキャッシュをもっているため、あらかじめファイル毎に最適なキャッシュ制御方式を選択しなければならない、という問題がある。
【０００９】
特開平１１−２１９３１７号公報は、アクセスコストをパラメータとする評価関数で算出された値が小さいファイルから順に削除する方法である。また、この関数を、ｆ（ｉ，ｃ）＝ｃ−１／（ｉ＋１）（ただし、ｉはアクセス順序、ｃはアクセスコスト）と与えることが示されている。この発明では、ファイルごとにアクセスコストが定義されていることを仮定しており、端末からのリクエストを処理する過程で生ずるアクセスコストの総和を少なくすることを目的としている。フォルトするデータ量をアクセスコストと考えると、ｃをファイルサイズと考えればよい。これにより、参照時刻が古くなるほど、ｆ（ｉ，ｃ）の値が小さくなるので、削除されやすくなるが、アクセスコストｃの値の分布によっては、ＬＲＵより極端にフォルト量が多くなることがある。
【００１０】
ＩＢＭの方式（Ｃ．Ａｇｇａｒｗａｌ，Ｊ．Ｗｏｌｆ，Ｐ．Ｙｕ，“Ｏｎ Ｃａｃｈｉｎｇ Ｐｏｌｉｃｉｅｓ ｆｏｒ Ｗｅｂ Ｏｂｊｅｃｔｓ”，ＩＢＭＲｅｓｅａｒｃｈ Ｒｅｐｏｒｔ ＲＣ２０６１９）では、サイズ×（現在時刻−最終参照時刻）を各ファイルのコストとして、コストが大きいファイルから順に削除する。この方法を用いることにより、最終参照時刻が古くなれば削除されやすくなるので、最悪の場合でもＬＲＵに比べて性能が際限なく悪くなることはない。しかし、サイズと（現在時刻−最終参照時刻）の積によってファイルのコストが表されるため、サイズの絶対値の大きさや分布に、フォルト量が大きく依存するという問題点がある。
【００１１】
【発明が解決しようとする課題】
本発明は上記の事情に鑑みてなされたもので、あるアクセスパターンを仮定したときに特に有効なキャッシュ制御方式を、ＬＲＵ方式と組み合わせることにより、仮定したアクセスパターンに対しては、ＬＲＵよりもさらにヒット率が高く、仮定したアクセスパターン以外に対しても、フォルトするデータ量の所定値が保証されるキャッシュ制御を用いたネットワークキャッシュ装置およびネットワークキャッシュ制御手法を提供することを目的とする。
【００１２】
【課題を解決するための手段】
上記目的を達成するために本発明は、ファイルを保存し提供するサーバーとファイルを利用する端末を結ぶネットワーク上に配置され、端末からリクエストされたファイルがファイル格納部にキャッシュされていれば、そのファイルをリクエスト元へ送出し、キャッシュされてなければファイルをサーバーから獲得し、リクエスト元へ送出すると同時にファイル格納部にキャッシュする、ネットワークキャッシュ装置において、端末から出されたリクエストの時系列を、リクエストされた相異なるファイルのサイズの合計がファイル格納部の容量を越えない最長の部分列に分割するとともに、各部分列におけるキャッシュフォルト回数を、ファイルごとに記憶しておくフォルト数管理テーブルと、ファイル格納部にキャッシュしたファイルごとに優先度を決める機能と、フォルト数管理テーブルに記憶されているファイルのフォルト数が所定の数に達したものにマークする機能を持ち、該キャッシュされたファイルごとに、該優先度と最終参照時刻に加え、マークされているかマークされていないかを区別する記号を記憶する、ファイル管理テーブルと、端末からリクエストされたファイルがファイル格納部にない場合、該サーバーから獲得したファイルを該ファイル格納部に格納するためのスペースがあれば、該サーバーから獲得したファイルを該ファイル格納部に格納し、該ファイル格納部に該サーバーから獲得したファイルを格納するためのスペースがない場合は、該端末からリクエストされたファイルを格納するスペースをつくるために、該ファイル管理テーブルに記憶された情報をもとに、優先度の低い順にファイルを選択し、マークされていないファイルであれば削除し、マークされているファイルであれば、それ以後は、該マークされているファイルも含めた残りのファイルの中から最終参照時刻が古い順に該ファイル格納部からファイルを削除した上で、該サーバーから獲得したファイルをファイル格納部に格納するキャッシュ制御部、を具備することを特徴とするものである。
【００１３】
また本発明は、サーバーに保存されているファイルをネットワークを介して利用する端末に具備され、端末からリクエストされたファイルがファイル格納部にキャッシュされていれば、そのファイルをリクエスト元へ送出し、キャッシュされてなければファイルをサーバーから獲得し、リクエスト元へ送出すると同時にファイル格納部にキャッシュする、ネットワークキャッシュ装置において、端末から出されたリクエストの時系列を、リクエストされた相異なるファイルのサイズの合計がファイル格納部の容量を越えない最長の部分列に分割するとともに、各部分列におけるキャッシュフォルト回数を、ファイルごとに記憶しておくフォルト数管理テーブルと、ファイル格納部にキャッシュしたファイルごとに優先度を決める機能と、フォルト数管理テーブルに記憶されているファイルのフォルト数が所定の数に達したものにマークする機能を持ち、該キャッシュされたファイルごとに、該優先度と最終参照時刻に加え、マークされているかマークされていないかを区別する記号を記憶する、ファイル管理テーブルと、端末からリクエストされたファイルがファイル格納部にない場合、該サーバーから獲得したファイルを該ファイル格納部に格納するためのスペースがあれば、該サーバーから獲得したファイルを該ファイル格納部に格納し、該ファイル格納部に該サーバーから獲得したファイルを格納するためのスペースがない場合は、該端末からリクエストされたファイルを格納するスペースをつくるために、該ファイル管理テーブルに記憶された情報をもとに、優先度の低い順にファイルを選択し、マークされていないファイルであれば削除し、マークされているファイルであれば、それ以後は、該マークされているファイルも含めた残りのファイルの中から最終参照時刻が古い順に該ファイル格納部からファイルを削除した上で、該サーバーから獲得したファイルをファイル格納部に格納するキャッシュ制御部、を具備することを特徴とするものである。
【００１４】
また本発明は、ファイルを保存し提供するサーバーとファイルを利用する端末を結ぶネットワーク上に配置され、端末からリクエストされたファイルがファイル格納部にキャッシュされていれば、そのファイルをリクエスト元へ送出し、キャッシュされてなければファイルをサーバーから獲得し、リクエスト元へ送出すると同時にファイル格納部にキャッシュする、ネットワークキャッシュ装置において、端末から出されたリクエストの時系列を、リクエストされた相異なるファイルのサイズの合計がファイル格納部の容量を越えない最長の部分列に分割するとともに、各部分列におけるキャッシュフォルト回数を、ファイルごとに記憶しておくフォルト数管理テーブルと、ファイル格納部にキャッシュしたファイルごとに優先度を決める機能と、フォルト数管理テーブルに記憶されているファイルのサイズに各々のキャッシュフォルト回数をかけた値の合計が所定の値を越えたときに、最後にリクエストされたファイルを含め、それ以後、前記部分列が終了するまでの間に、リクエストされたファイルにマークする機能を持ち、該キャッシュされたファイルごとに、該優先度と最終参照時刻に加え、マークされているかマークされていないかを区別する記号を記憶する、ファイル管理テーブルと、端末からリクエストされたファイルがファイル格納部にない場合、該サーバーから獲得したファイルを該ファイル格納部に格納するためのスペースがあれば、該サーバーから獲得したファイルを該ファイル格納部に格納し、該ファイル格納部に該サーバーから獲得したファイルを格納するためのスペースがない場合は、該端末からリクエストされたファイルを格納するスペースをつくるために、該ファイル管理テーブルに記憶された情報をもとに、優先度の低い順にファイルを選択し、マークされていないファイルであれば削除し、マークされているファイルであれば、それ以後は、該マークされているファイルも含めた残りのファイルの中から最終参照時刻が古い順に該ファイル格納部からファイルを削除した上で、該サーバーから獲得したファイルをファイル格納部に格納するキャッシュ制御部、を具備することを特徴とするものである。
【００１５】
また本発明は、サーバーに保存されているファイルをネットワークを介して利用する端末に具備され、端末からリクエストされたファイルがファイル格納部にキャッシュされていれば、そのファイルをリクエスト元へ送出し、キャッシュされてなければファイルをサーバーから獲得し、リクエスト元へ送出すると同時にファイル格納部にキャッシュする、ネットワークキャッシュ装置において、端末から出されたリクエストの時系列を、リクエストされた相異なるファイルのサイズの合計がファイル格納部の容量を越えない最長の部分列に分割するとともに、各部分列におけるキャッシュフォルト回数を、ファイルごとに記憶しておくフォルト数管理テーブルと、ファイル格納部にキャッシュしたファイルごとに優先度を決める機能と、フォルト数管理テーブルに記憶されているファイルのサイズに各々のキャッシュフォルト回数をかけた値の合計が所定の値を越えたときに、最後にリクエストされたファイルを含め、それ以後、前記部分列が終了するまでの間に、リクエストされたファイルにマークする機能を持ち、該キャッシュされたファイルごとに、該優先度と最終参照時刻に加え、マークされているかマークされていないかを区別する記号を記憶する、ファイル管理テーブルと、端末からリクエストされたファイルがファイル格納部にない場合、該サーバーから獲得したファイルを該ファイル格納部に格納するためのスペースがあれば、該サーバーから獲得したファイルを該ファイル格納部に格納し、該ファイル格納部に該サーバーから獲得したファイルを格納するためのスペースがない場合は、該端末からリクエストされたファイルを格納するスペースをつくるために、該ファイル管理テーブルに記憶された情報をもとに、優先度の低い順にファイルを選択し、マークされていないファイルであれば削除し、マークされているファイルであれば、それ以後は、該マークされているファイルも含めた残りのファイルの中から最終参照時刻が古い順に該ファイル格納部からファイルを削除した上で、該サーバーから獲得したファイルをファイル格納部に格納するキャッシュ制御部、を具備することを特徴とするものである。
【００１６】
また本発明は、前記ネットワークキャッシュ装置において、ファイル管理テーブルに記載されるファイルの優先度が１／（ファイルのサイズ）であることを特徴とするものである。
【００１７】
また本発明は、前記ネットワークキャッシュ装置において、フォルト数管理テーブルが、端末からリクエストされたファイルの、サイズと、キャッシュにおけるフォルト回数と、を記憶し、記憶したファイルのサイズの合計が、該ファイル格納部の容量を越える直前に、それまで記憶した情報を全て削除する機能を持つことを特徴とするものである。
【００１８】
また本発明は、ファイルを保存し提供するサーバーとファイルを利用する端末を結ぶネットワーク上に配置され、端末からリクエストされたファイルがファイル格納部にキャッシュされていれば、そのファイルをリクエスト元へ送出し、キャッシュされてなければファイルをサーバーから獲得し、リクエスト元へ送出すると同時にファイル格納部にキャッシュする、ネットワークキャッシュ制御手法において、端末から出されたリクエストの時系列を、リクエストされた相異なるファイルのサイズの合計がファイル格納部の容量を越えない最長の部分列に分割するとともに、各部分列におけるキャッシュフォルト回数を、ファイルごとにフォルト数管理テーブルに記憶しておくフォルト数管理テーブル記憶ステップと、ファイル格納部にキャッシュしたファイルごとに優先度を決める機能と、フォルト数管理テーブルに記憶されているファイルのフォルト数が所定の数に達したものにマークする機能を持つファイル管理テーブルに、該キャッシュされたファイルごとに、該優先度と最終参照時刻に加え、マークされているかマークされていないかを区別する記号を記憶する、ファイル管理テーブル記憶ステップと、端末からリクエストされたファイルがファイル格納部にない場合、該サーバーから獲得したファイルを該ファイル格納部に格納するためのスペースがあれば、該サーバーから獲得したファイルを該ファイル格納部に格納し、該ファイル格納部に該サーバーから獲得したファイルを格納するためのスペースがない場合は、該端末からリクエストされたファイルを格納するスペースをつくるために、該ファイル管理テーブルに記憶された情報をもとに、優先度の低い順にファイルを選択し、マークされていないファイルであれば削除し、マークされているファイルであれば、それ以後は、該マークされているファイルも含めた残りのファイルの中から最終参照時刻が古い順に該ファイル格納部からファイルを削除した上で、該サーバーから獲得したファイルを該ファイル格納部に格納するキャッシュ制御ステップ、を具備することを特徴とする。
【００１９】
また本発明は、ファイルを保存し提供するサーバーとファイルを利用する端末を結ぶネットワーク上に配置され、端末からリクエストされたファイルがファイル格納部にキャッシュされていれば、そのファイルをリクエスト元へ送出し、キャッシュされてなければファイルをサーバーから獲得し、リクエスト元へ送出すると同時にファイル格納部にキャッシュする、ネットワークキャッシュ制御手法において、端末から出されたリクエストの時系列を、リクエストされた相異なるファイルのサイズの合計がファイル格納部の容量を越えない最長の部分列に分割するとともに、各部分列におけるキャッシュフォルト回数を、ファイルごとにフォルト数管理テーブルに記憶しておくフォルト数管理テーブル記憶ステップと、ファイル格納部にキャッシュしたファイルごとに優先度を決める機能と、フォルト数管理テーブルに記憶されているファイルのサイズに各々のキャッシュフォルト回数をかけた値の合計が所定の値を越えたときに、最後にリクエストされたファイルを含め、それ以後、前記部分列が終了するまでの間に、リクエストされたファイルにマークする機能を持つファイル管理テーブルに、該キャッシュされたファイルごとに、該優先度と最終参照時刻に加え、マークされているかマークされていないかを区別する記号を記憶する、ファイル管理テーブル記憶ステップと、端末からリクエストされたファイルがファイル格納部にない場合、該サーバーから獲得したファイルを該ファイル格納部に格納するためのスペースがあれば、該サーバーから獲得したファイルを該ファイル格納部に格納し、該ファイル格納部に該サーバーから獲得したファイルを格納するためのスペースがない場合は、該端末からリクエストされたファイルを格納するスペースをつくるために、該ファイル管理テーブルに記憶された情報をもとに、優先度の低い順にファイルを選択し、マークされていないファイルであれば削除し、マークされているファイルであれば、それ以後は、該マークされているファイルも含めた残りのファイルの中から最終参照時刻が古い順に該ファイル格納部からファイルを削除した上で、該サーバーから獲得したファイルを該ファイル格納部に格納するキャッシュ制御ステップ、を具備することを特徴とする。
【００２０】
また本発明は、前記ネットワークキャッシュ制御手法において、ファイル管理テーブルに記憶されるファイルの優先度が１／（ファイルのサイズ）であることを特徴とする。
【００２１】
また本発明は、前記ネットワークキャッシュ制御手法において、フォルト数管理テーブルが、端末からリクエストされたファイルの、サイズと、キャッシュにおけるフォルト回数と、を記憶し、記憶したファイルのサイズの合計が、該ファイル格納部の容量を越える直前に、それまで記憶した情報を全て削除する機能を持つことを特徴とする。
【００２２】
【発明の実施の形態】
以下図面を参照して本発明の実施形態例を詳細に説明する。
【００２３】
［実施形態例１］
図１は本発明の実施形態例１を示す構成説明図である。図において、１１はサーバー、１２は端末、１３はネットワーク、１４はネットワークキャッシュ装置、１５はファイル格納部、１６はフォルト数管理テーブル、１７はファイル管理テーブル、１８はキャッシュ制御部である。すなわち、ネットワークキャッシュ装置１４はファイルを保存し提供するサーバー１１とファイルを利用する端末１２を結ぶネットワーク１３上に配置され、前記端末１２からリクエストされたファイルがファイル格納部１５にキャッシュされていれば、そのファイルをリクエスト元へ送出し、キャッシュされてなければファイルをサーバー１１から獲得し、リクエスト元へ送出すると同時にファイル格納部１５にキャッシュする。
【００２４】
尚、ネットワークキャッシュ装置は、サーバーに保存されているファイルをネットワークを介して利用する端末に具備されるようにしてもよい。
【００２５】
前記フォルト数管理テーブル１６は、キャッシュされたファイルのファイル名、サイズおよびフォルト回数を、１エントリとして記憶する。フォルト数管理テーブル１６の一例を図８に示す。端末１２からリクエストされたファイルがファイル格納部１５にあるとき、そのファイルのエントリがフォルト数管理テーブル１６になければ、新しいエントリをつくり、そのフォルト回数を０に設定する。端末１２からリクエストされたファイルがファイル格納部１５にないとき、サーバー１１から獲得したファイルＡが、フォルト数管理テーブル１６内にあれば、該当するエントリのフォルト回数を１増やし、フォルト数管理テーブル１６内になければ新しくエントリをつくり、そのフォルト回数は１に設定する。フォルト数管理テーブル１６に新しくエントリを作るとき、すでにあるエントリのサイズの合計と新しく作るエントリのサイズの和がファイル格納部１５の容量を越えるときは、すべてのエントリを削除してから、新しいエントリをつくる。
【００２６】
前記ファイル管理テーブル１７は、キャッシュされたファイルのファイル名、優先度、最終参照時刻、フォルト数管理テーブル１６に記憶されているフォルト回数が所定の数に達していることを示すマーク、とを１エントリとして記憶する。ファイル管理テーブル１７の一例を図９に示す。最終参照時刻は、参照される度に更新される。優先度は、予めサーバー１１等によって決められたものでもよいし、ファイルのサイズや属性をもとにファイル管理テーブル１７が決めたものであっても良い。フォルト数管理テーブル１６のエントリがすべて削除されたときには、すべてのマークを無効化する。ただし、ここでマークを無効化することは、必須ではなく、一度マークされたものはそのままにしておいてもよい。ファイル管理テーブル１７は、ファイル格納部１５に実際に格納されているファイルのリストである。したがって、ファイル管理テーブル１７へのエントリの挿入・削除は、ファイル格納部１５へのファイルの挿入・削除と連係して行なわれる。
【００２７】
前記キャッシュ制御部１８は、ファイル管理テーブル１７を用いて、ファイル格納部１５に対するファイルの挿入・削除を管理する。端末１２からリクエストされたファイルがファイル格納部１５にない場合、このファイルをファイル格納部１５に格納するためのスペースがあれば、ファイル格納部１５に格納する。スペースが十分にない場合は、ファイル管理テーブル１７に記憶された情報をもとに、優先度の低い順にファイルを選択し、マークされていないファイルであれば削除し、マークされているファイルであれば、そのファイルも含めた残りのファイルの中から最終参照時刻が古い順にファイル格納部１５からファイルを削除することにより、ファイルを格納するための空きスペースをつくる。その上で、サーバー１１から獲得したファイルをファイル格納部１５に格納する。
【００２８】
図５は前記フォルト数管理テーブル１６、前記ファイル管理テーブル１７及び前記キャッシュ制御部１８の動作を示すフローチャートであり、図６は図５のフォルト数管理テーブルチェック操作を示すフローチャートであり、図７は図５のファイル挿入操作を示すフローチャートである。すなわち、図５に示すように、端末１２からファイルＡへのリクエストがあり、ステップＳ１でファイルＡがファイル格納部１５にあると、ステップＳ２でファイルＡの最終参照時刻を更新し、ステップＳ３でファイルＡがフォルト数管理テーブル１６にあればステップＳ４で処理を終了する。前記ステップＳ３でファイルＡがフォルト数管理テーブル１６になければ、ステップＳ５でフォルト数管理テーブル１６のチェック操作を行う。フォルト数管理テーブル１６のチェック操作は、図６に示すように、ステップＳ６１で「フォルト数管理テーブル１６に記憶されるファイルのサイズの和」＋「ファイルＡのサイズ」＞「ファイル格納部１５の容量」であれば、ステップＳ６２でフォルト数管理テーブル１６をクリアし、ステップＳ６３でファイル管理テーブル１７の全てのマークを無効化し、図５のステップＳ６でフォルト数管理テーブル１６にファイルＡのエントリを作成し、フォルト回数＝０に設定し、ステップＳ４で処理を終了する。前記ステップＳ１でファイルＡがファイル格納部１５になければ、ステップＳ７でファイルＡをサーバー１１から獲得し、ステップＳ８でファイルＡがフォルト数管理テーブル１６にあれば、ステップＳ９でファイルＡのフォルト回数を１増加させる。前記ステップＳ８でファイルＡがフォルト数管理テーブル１６になければ、ステップＳ１０で図６に示すようなフォルト数管理テーブル１６のチェック操作を行い、ステップＳ１１でフォルト数管理テーブル１６にファイルＡのエントリを作成し、フォルト回数＝１に設定する。ステップＳ１２でファイル格納部１５にファイルＡを入れるスペースがあれば、ステップＳ１３でファイル挿入操作を行う。ファイル挿入操作は、図７に示すように、ステップＳ７１でファイルＡをファイル格納部１５へ挿入し、ステップＳ７２でファイル管理テーブル１７のファイルＡのエントリに優先度・最終参照時刻を設定する。ステップＳ７３でフォルト数管理テーブル１６においてファイルＡのフォルト数が所定の数に等しければ、ステップＳ７４でファイル管理テーブル１７のファイルＡのエントリにマークする。前記ステップＳ１２でファイル格納部１５にファイルＡを入れるスペースがなければ、ステップＳ１４で優先度が最低のファイルを選択し、ステップＳ１５でマークされていなければ、ステップＳ１６でファイルを削除する。前記ステップＳ１５でマークされていれば、ステップＳ１７で最終参照時刻が最も古いファイルを削除し、ステップＳ１８でファイル格納部１５にファイルＡを入れるスペースがあれば、ステップＳ１３で図７に示すようなファイル挿入操作を行う。
【００２９】
次に、ファイルの優先度が１／（ファイルのサイズ）に等しい場合の動作例を示す。また、ファイル格納部１５の容量は１０とし、フォルト数管理テーブル１６に記憶されているフォルト数が２に達したとき、ファイル管理テーブル１７のエントリにマークをつけるものとする。
【００３０】
以下では、説明を簡潔にするため、ファイル管理テーブル１７とファイル格納部１５を区別しない。また、ファイル管理テーブル１７に実際に記憶されるのは、ファイルのエントリであるが、混乱の恐れがない限り、ファイルとエントリを区別しないものとする。
【００３１】
いま、図２に示すファイルがリクエストされるものとする。図３は、２行目に示す系列に従って、ファイルがリクエストされたときの、ファイル管理テーブル１７およびフォルト数管理テーブル１６の内容を示している。シーケンス番号は、説明の便宜上つけたものである。フォルト数管理テーブル１６の行には、各エントリのファイル名とフォルト数が示されている。例えば、Ａ（２）というのは、ファイル名はＡで、フォルト数は２であることを意味している。フォルト数管理テーブル１６がクリア（全部のエントリが削除）された時刻を、縦２重線で示している。実際には、ファイルがリクエストされてから、フォルト数管理テーブル１６をクリアするかどうかを判断するが、便宜上、クリアする原因となったリクエストの直前にクリアされるものとする。フォルト数管理テーブル１６がクリアされるときのリクエストから、次にクリアされる直前のリクエストまでを、フェーズと呼ぶことにする。すなわち、フェーズは、端末から出されたリクエストの時系列を分割してできる連続部分列であって、リクエストされた相異なるファイルのサイズの合計がファイル格納部１５の容量を越えない最長の部分列である。
【００３２】
最初、キャッシュは空なので、３番目までのリクエストは全てフォルトし、３つのファイルは、全て、ファイル格納部に格納される。これら３つのリクエストは、全てフォルトするため、フォルト数管理テーブル１６に加えられるエントリのフォルト数は１に設定される。
【００３３】
４番めのリクエストでファイルＢが要求されたとき、ファイルＢのエントリをフォルト数管理テーブル１６に加えると、フォルト数管理テーブル１６にある各エントリのサイズの合計はファイル格納部の容量、１０、を越えるので、フォルト数管理テーブル１６をクリアしてから、ファイルＢのエントリを加える。ファイル管理テーブル１７も同様に、ファイルＢのエントリを加えると、エントリのサイズの合計が１０を越えるので、ファイルＡ、Ｃ、Ｄのうち最も優先度が低いＡを削除し、ファイルＢのエントリを加える。
【００３４】
５番目、６番目のリクエストについても、４番目と同様である。
【００３５】
７番目のリクエストで、ファイルＢへのリクエストがフォルトするが、すでに、フォルト数管理テーブル１６にＢのエントリが存在するので、フォルト数を１増加させ、２とする。フォルト数が２に達したので、ファイル管理テーブル１７にＢのエントリを作るときに、同時にマーク（*）をつける。
【００３６】
８番目のリクエストで、ファイルＡへのリクエストがフォルトするので、ファイルＡのエントリをファイル管理テーブル１７に加えるために、他のエントリを削除しなければならない。優先度が低い順では、Ｂが削除されることになるが、Ｂにはマーク（*）がついているので、ＬＲＵで削除する。ＬＲＵ順では、Ｄが最も参照時刻が古いので、削除される。フォルト数管理テーブル１６には、すでにファイルＡのエントリが存在するので、フォルト数を１増加させ、２とする。フォルト数が２に達したので、ファイル管理テーブル１７にＡのエントリを作るときに、同時にマーク（*）をつける。
【００３７】
９番目、１０番めのリクエストは、ファイルＢ、ファイルＡへのリクエストである。これらは、ヒットする。
【００３８】
１１番目のリクエストでフォルトが起き、ここで次のフェーズに移行する。
【００３９】
１２番目のリクエストは、ファイルＥへのリクエストであるので、ヒットする。しかし、このフェーズにおいては、ファイルＥへのリクエストは、初めてであり、フォルト数管理テーブル１６にそのエントリが存在しない。このため、フォルト数管理テーブル１６に、ファイルＥのエントリが加えられる。ただし、フォルトはしていないので、フォルト数は０に設定される。
【００４０】
各フェーズ内では、リクエストされる相異なるファイルのサイズの合計は、常にファイル格納部１５の容量以下である。
【００４１】
また、任意のフェーズにおいて、マークされたファイルがＬＲＵによって削除されることはない。理由は以下の通りである。
【００４２】
すなわち、ファイルＰをファイル格納部１５へ入れるために、マークされたファイルＱがＬＲＵによって、削除されたとすると、ファイルＰ、ファイルＱ及び、ファイルＱよりも最終参照時刻が新しいファイルはすべて、当該フェーズでリクエストされたことになる。よって、これらのファイルのサイズの和は、ファイル格納部１５の容量以下である。これは、ファイルＱが削除されることに矛盾する。よって、当該フェーズ内に、ファイルＱが削除されることはない。
【００４３】
マークされたファイルは、優先度が低い順でもＬＲＵでも削除されることはない。よって、各フェーズでフォルトする回数は、そのフェーズ内でリクエストされる各ファイルにつき高々２回である。従って、フォルトしたデータ容量（フォルト量）は、ファイル格納部１５の容量の高々２倍である。
【００４４】
フォルト数管理テーブル１６に記憶されているフォルト数がＮ（Ｎは１以上とする）に達したとき、ファイル管理テーブル１７のエントリにマークをつけることにすると、各フェーズでフォルトする回数は、そのフェーズ内でリクエストされる各ファイルにつき高々Ｎ回である。フォルト量の点からは、ファイル格納部１５の容量の高々Ｎ倍ということになる。従って、Ｎを増やすほど優先度が低い順に削除される可能性は高くなるが、各フェーズでのフォルト量の最悪値も大きくなる。
【００４５】
前記のように、フォルト数管理テーブル１６がクリアされたときにマークを無効化しない場合においても、現在のフェーズでマークされたファイルについては、優先度順でもＬＲＵでも削除されることはないので、各フェーズでフォルトするデータ容量（フォルト量）は、ファイル格納部１５の容量の高々Ｎ倍である。
【００４６】
一方、ＬＲＵのみを用いた場合は、端末１２から出されたリクエストの時系列を分割してできる連続部分列であって、その部分列の中でリクエストされる相異なるファイルのサイズの総和が、高々ファイル格納部１５の容量であるような任意の部分列の中で、同一のファイルに対するリクエストがフォルトする回数は高々１回であり、フォルト量は高々ファイル格納部１５の容量である。これは、以下の理由による。
【００４７】
すなわち、リクエストの上記部分列の中でフォルトしてファイル格納部１５に入れられたファイルＱが、ファイルＰをファイル格納部１５へ入れるために、ＬＲＵによって、削除されたとする。ファイルＰ、ファイルＱ及び、ファイルＱよりも最終参照時刻が新しいファイルはすべて、当該部分列でリクエストされたことになる。よって、これらのファイルのサイズの和は、ファイル格納部１５の容量以下である。これは、ファイルＱが削除されることに矛盾する。したがって、上記部分列を処理する間は、ファイルＱは削除されない。
【００４８】
このことから、ＬＲＵを用いた場合に起こり得るフォルト回数およびフォルト量の最悪値にくらべて、本発明の方法を用いた場合に起こり得るフォルト回数およびフォルト量の最悪値は、高々Ｎ倍で抑えられる。つまり、Ｎの値を大きくすることにより、優先度のみに基づくキャッシュ制御に近い動作をさせたり、Ｎの値を小さくすることにより、ＬＲＵのみを用いたキャッシュ制御に近い動作をさせることができる。
【００４９】
［実施形態例２］
フォルト数管理テーブル１６に格納されている各ファイルに対して、フォルト数×サイズの合計を、フォルト数管理テーブル１６が更新されるごとに計算する。この値をフェーズのフォルト量と呼ぶことにする。任意のフェーズにおいて、あるリクエストを処理するためにフォルト数管理テーブル１６が更新された結果、フェーズのフォルト量が所定の値Ｔを越えたとすると、このときリクエストされたファイルを含めて、これ以後、このフェーズの中でファイル管理テーブル１７に入ったエントリにマークをつける。このようにすることで、フェーズのフォルト量がＴを越えてから後は、同一フェーズ内で、各ファイルは、高々１回しかフォルトしないので、各フェーズでフォルト量は、高々、（ファイル格納部１５の容量）＋Ｔとなる。
【００５０】
図４をもとに説明する。図４は、図３と同じリクエスト列に対する、ファイル管理テーブル１７およびフォルト数管理テーブル１６の、Ｔ＝８に対する動作を示している。
【００５１】
３番目のリクエストは、ファイルＤに対するリクエストであるので、ファイルＤのエントリをフォルト数管理テーブル１６に加える。その結果、フォルト数管理テーブル１６内のエントリのサイズの合計がＴを越えるので、ファイル管理テーブル１７に、ファイルＤのエントリをつくり、マークをつける。
【００５２】
４番目のリクエスト直前に、フォルト数管理テーブル１６がクリアされるのは実施形態例１と同様である。
【００５３】
６番目のリクエストの際に、ファイルＥのエントリをフォルト数管理テーブル１６に加える。その結果、フォルト数管理テーブル１６内のエントリのサイズの合計がＴを越えるので、ファイル管理テーブル１７に、ファイルＥのエントリをつくり、マーク（*）をつける。これ以後、フェーズが終了するまで、フォルトが起こったリクエストに対し、フォルト数管理テーブル１６内のエントリのサイズの合計がＴを越えるので、ファイル管理テーブル１７内の新しく加えられたエントリには全てマーク（*）される。
【００５４】
１６番目、１７番目のリクエストに関しても同様である。
【００５５】
【発明の効果】
以上述べたように本発明によれば、あるアクセスパターンを仮定したときに特に有効なキャッシュ制御方式を、ＬＲＵ方式と組み合わせることにより、仮定したアクセスパターンに対しては、ＬＲＵよりもさらにヒット率が高く、仮定したアクセスパターン以外に対しても、フォルトするデータ量の所定値が保証されるキャッシュ制御を用いたネットワークキャッシュ装置およびネットワークキャッシュ制御手法を提供することができる。
【図面の簡単な説明】
【図１】本発明の実施形態例１を示す構成説明図である。
【図２】本発明に係るファイルの一例を示す説明図である。
【図３】本発明の実施形態例１に係るファイルの要求列に対するファイル管理テーブルおよびフォルト数管理テーブルの状態遷移を示す説明図である。
【図４】本発明の実施形態例２に係るファイルの要求列に対するファイル管理テーブルおよびフォルト数管理テーブルの状態遷移を示す説明図である。
【図５】本発明の実施形態例１に係るフォルト数管理テーブル、ファイル管理テーブル及びキャッシュ制御部の動作を示すフローチャートである。
【図６】図５のフォルト数管理テーブルチェック操作を示すフローチャートである。
【図７】図５のファイル挿入操作を示すフローチャートである。
【図８】本発明に係るフォルト数管理テーブルの一例を示す説明図である。
【図９】本発明に係るファイル管理テーブルの一例を示す説明図である。
【符号の説明】
１１ サーバー
１２ 端末
１３ ネットワーク
１４ ネットワークキャッシュ装置
１５ ファイル格納部
１６ フォルト数管理テーブル
１７ ファイル管理テーブル
１８ キャッシュ制御部[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a network cache apparatus and a network cache control method that are arranged on a network connecting a server that stores and provides a file and a terminal that uses the file, or is provided in the terminal.
[0002]
[Prior art]
When caching a file sent from a new server in a cache arranged in a network or a client terminal connected to the network, if there is not enough space in the cache, the file is deleted. A means to determine whether or not At this time, in order to reduce the amount of data faulted in the cache (the sum of the sizes of the faulted files), it is desirable to use a cache control method that leaves files with high reference frequency in the cache and deletes files with low reference frequency. .
[0003]
As a cache control method, a method called LRU (Least Recently Used) that deletes pages in order from the page with the oldest reference time is common. This was originally devised as a paging technique in a virtual storage system. In general, a program has local referentiality that allows easy access to a recently accessed page. The LRU uses this local referential property to delete a file with a low reference frequency.
[0004]
A request to a file issued from an application such as a WWW (World Wide Web) browser activated by a terminal also has this local reference, so the LRU method is considered to be effective for caching in a network.
[0005]
When attention is paid not only to the reference time but also to the size, there are cases where small files tend to be accessed more frequently as in the case of WWW traffic. In such a case, the Size method in which the file is deleted with priority over the LRU method is more effective than the LRU (reference document: S. Williams and M. Abrams and C. R. Strandridge and G. Abdulla. and EA Fox, “Removable Policies in Network Caches for World-Wide-Web Documents”, Processeds of SIGCOMM, ACM, 1996). This is because the LRU method is not deleted until the reference time becomes the oldest in the cache, even if the file once entered into the cache is rarely referenced. This is because the largest cached file is deleted immediately. Further, when the reference frequency can be predicted for file attributes such as an image file and a text file, a high priority is given to a file having a high reference frequency attribute, and an effect similar to that of the Size method can be obtained.
[0006]
However, in the cache control method that assumes the size of the requested file and the distribution of attributes as described above, the reference frequency is not taken into consideration, so if the assumption is broken or the assumption does not apply. If not, the amount of data that is extremely faulty may increase. For example, when the Size method is used, if requests for a file larger than any cached file continue, the file just entered in the cache is immediately deleted, and the amount of faulted data becomes extremely large. There was a problem.
[0007]
Japanese Patent Laid-Open No. 7-182220 divides cached files into a first group that deletes files in descending order of priority and a second group that deletes files with LRU. When deleting an already cached file in order to cache a new object, one of the two groups is appropriately selected and deleted. However, depending on how the group is selected, there is a problem that the fault amount becomes extremely large.
[0008]
Japanese Patent Application Laid-Open No. 11-65927 is a method having a plurality of storages with different cache control methods. However, since this has a plurality of independent caches, there is a problem that an optimal cache control method must be selected for each file in advance.
[0009]
Japanese Patent Application Laid-Open No. 11-219317 is a method of deleting files in order from the smallest value calculated by the evaluation function using the access cost as a parameter. It is also shown that this function is given as f (i, c) = c−1 / (i + 1) (where i is the access order and c is the access cost). In the present invention, it is assumed that an access cost is defined for each file, and an object is to reduce the sum of access costs generated in the process of processing a request from a terminal. Considering the amount of data to fault as the access cost, c can be considered as the file size. As a result, the older the reference time is, the smaller the value of f (i, c) becomes, so it is easier to delete it. However, depending on the distribution of the value of access cost c, the amount of faults may be extremely greater than LRU. .
[0010]
In the IBM method (C. Aggarwal, J. Wolf, P. Yu, “On Caching Policies for Web Objects”, IBM Research Report RC 20619), the cost is the size × (current time−final reference time) as the cost of each file. Delete from the largest file. By using this method, if the last reference time becomes old, it is easy to be deleted. Therefore, even in the worst case, the performance is not indefinitely deteriorated as compared with the LRU. However, since the cost of the file is represented by the product of the size and (current time−last reference time), there is a problem that the fault amount greatly depends on the size and distribution of the absolute value of the size.
[0011]
[Problems to be solved by the invention]
The present invention has been made in view of the above circumstances, and by combining a cache control method particularly effective when an access pattern is assumed with the LRU method, the assumed access pattern is further improved than LRU. It is an object of the present invention to provide a network cache device and a network cache control method using cache control in which a hit rate is high and a predetermined value of a data amount to be faulted is guaranteed even for an access pattern other than the assumed access pattern.
[0012]
[Means for Solving the Problems]
In order to achieve the above object, the present invention is arranged on a network connecting a server that stores and provides a file and a terminal that uses the file, and if the file requested from the terminal is cached in the file storage unit, Sends the file to the request source, acquires the file from the server if it is not cached, sends it to the request source, and simultaneously caches it in the file storage unit. The total number of different files that have been generated is divided into the longest subsequence that does not exceed the capacity of the file storage unit, and the number of cache faults in each subsequence is stored for each file, and a file Files cached in the storage Has a function for determining the priority and a function for marking the number of faults of a file stored in the fault number management table to a predetermined number, and the priority and final reference for each cached file. In addition to the time, a file management table that stores a symbol for distinguishing whether it is marked or not, and when the file requested by the terminal is not in the file storage unit, the file acquired from the server is stored in the file If there is a space for storing the file, the file acquired from the server is stored in the file storage unit. If there is no space for storing the file acquired from the server in the file storage unit, the terminal Stored in the file management table to create a space for storing files requested by Based on the information, select the files in order of priority, delete them if they are not marked, and if they are marked, include the marked files after that A cache control unit for storing files acquired from the server in the file storage unit after deleting the files from the file storage unit in order of the last reference time from the remaining files It is.
[0013]
In addition, the present invention is provided in a terminal that uses a file stored in a server via a network, and if the file requested from the terminal is cached in the file storage unit, the file is sent to the request source, If it is not cached, the file is acquired from the server, sent to the request source, and simultaneously cached in the file storage unit. The total is divided into the longest partial columns that do not exceed the capacity of the file storage unit, the number of cache faults in each partial column is stored for each file, and for each file cached in the file storage unit A function to determine the priority Whether the number of file faults stored in the file number management table reaches the specified number, and whether each file is cached is marked in addition to the priority and the last reference time. A file management table for storing a symbol for distinguishing whether the file is not marked, and a file requested from the terminal are not in the file storage unit, there is a space for storing the file acquired from the server in the file storage unit. If there is, the file acquired from the server is stored in the file storage unit. If there is no space for storing the file acquired from the server in the file storage unit, the file requested from the terminal is stored. Low priority based on information stored in the file management table to create space If a file is not marked, it is deleted. If it is a marked file, the last reference time is the oldest among the remaining files including the marked file. And a cache control unit that sequentially deletes the file from the file storage unit and stores the file acquired from the server in the file storage unit.
[0014]
Also, the present invention is arranged on a network connecting a server that stores and provides a file and a terminal that uses the file, and if the file requested from the terminal is cached in the file storage unit, the file is sent to the request source. If it is not cached, the network acquires the file from the server, sends it to the request source, and simultaneously caches it in the file storage unit. The total size is divided into the longest partial columns that do not exceed the capacity of the file storage unit, and the number of cache faults in each partial column is stored for each file, and the file cached in the file storage unit Machine to determine priority for each When the total of the file size stored in the fault count management table multiplied by the number of cache faults exceeds a predetermined value, the last requested file is included. Have the ability to mark the requested file before the end of the sequence, and for each cached file, distinguish between marked and unmarked, in addition to the priority and last reference time If the file storage table storing the symbol and the file requested from the terminal are not in the file storage unit, the file acquired from the server is acquired from the server if there is space to store it in the file storage unit Store the file in the file storage unit, and store the file acquired from the server in the file storage unit If there is no space to store the file requested by the terminal, the file is selected in the order of low priority based on the information stored in the file management table, and marked. If it is a file that has not been deleted, the file is deleted. If it is a file that has been marked, thereafter, the file from the file storage unit is sorted in order of the last reference time from among the remaining files including the marked file. And a cache control unit for storing the file acquired from the server in the file storage unit.
[0015]
In addition, the present invention is provided in a terminal that uses a file stored in a server via a network, and if the file requested from the terminal is cached in the file storage unit, the file is sent to the request source, If it is not cached, the file is acquired from the server, sent to the request source, and simultaneously cached in the file storage unit. In the network cache device, the time series of requests issued from the terminal are changed to the size of the requested different file size. The total is divided into the longest partial columns that do not exceed the capacity of the file storage unit, the number of cache faults in each partial column is stored for each file, and for each file cached in the file storage unit A function to determine the priority When the total of the size of the file stored in the file number management table multiplied by the number of cache faults exceeds a predetermined value, the last requested file is included. It has a function to mark the requested file until the end, and for each cached file, in addition to the priority and the last reference time, a symbol that distinguishes whether it is marked or not marked When the file management table to be stored and the file requested from the terminal are not in the file storage unit, if there is a space for storing the file acquired from the server in the file storage unit, the file acquired from the server is stored. For storing in the file storage unit and storing the file acquired from the server in the file storage unit; If there is no pace, files are selected from the lowest priority based on the information stored in the file management table in order to create a space for storing the file requested by the terminal, and are not marked. If it is a file, it is deleted, and if it is a marked file, the files are deleted from the file storage unit in the order of the last reference time from the remaining files including the marked file. A cache control unit for storing a file acquired from the server in a file storage unit is provided.
[0016]
Also, the present invention is characterized in that, in the network cache device, the priority of the file described in the file management table is 1 / (file size).
[0017]
In the network cache device, the fault number management table stores the size of the file requested from the terminal and the number of faults in the cache, and the total size of the stored file is stored in the file storage. It is characterized by having a function of deleting all the information stored so far just before the capacity of the copy is exceeded.
[0018]
Also, the present invention is arranged on a network connecting a server that stores and provides a file and a terminal that uses the file, and if the file requested from the terminal is cached in the file storage unit, the file is sent to the request source. If it is not cached, the file is acquired from the server, sent to the request source, and simultaneously cached in the file storage unit. In the network cache control method, the time series of requests issued from the terminal are changed to the different requested files. A fault number management table storage step for storing the number of cache faults in each partial column in the fault number management table for each file, and dividing the longest partial column that does not exceed the capacity of the file storage unit. In the file storage For each cached file in the file management table that has the function of determining the priority for each file that has been deleted, and the function of marking the number of file faults stored in the fault number management table as having reached a predetermined number. In addition to the priority and the last reference time, a file management table storing step for storing a symbol for distinguishing whether it is marked or not, and when the file requested from the terminal is not in the file storage unit, If there is a space for storing the file acquired from the server in the file storage unit, the file acquired from the server is stored in the file storage unit, and the file acquired from the server is stored in the file storage unit If there is no space to store the file requested by the terminal To create a pace, based on the information stored in the file management table, select a file in the order of priority, delete it if it is not marked, and if it is marked, Thereafter, the files acquired from the server are stored in the file storage unit after the files are deleted from the file storage unit in order of the last reference time from the remaining files including the marked file. And a cache control step.
[0019]
Also, the present invention is arranged on a network connecting a server that stores and provides a file and a terminal that uses the file, and if the file requested from the terminal is cached in the file storage unit, the file is sent to the request source. If it is not cached, the file is acquired from the server, sent to the request source, and simultaneously cached in the file storage unit. In the network cache control method, the time series of requests issued from the terminal are changed to the different requested files. A fault number management table storage step for storing the number of cache faults in each partial column in the fault number management table for each file, and dividing the longest partial column that does not exceed the capacity of the file storage unit. In the file storage This function is requested last when the sum of the value obtained by multiplying the number of cache faults by the file size stored in the fault count management table exceeds the predetermined value. In the file management table having the function of marking the requested file until the end of the subsequence, the priority and the last reference time are set for each cached file. In addition, a file management table storage step for storing a symbol for distinguishing whether the file is marked or not, and when the file requested by the terminal is not in the file storage unit, the file acquired from the server is stored in the file If there is space to store the file, the file acquired from the server If there is no space for storing the file acquired from the server in the file storage unit, the file management table stores the file requested by the terminal. Based on the stored information, files are selected in order of priority, deleted if they are not marked, and if they are marked, the marked files are A cache control step of deleting the file from the file storage unit in order of the last reference time from the remaining files included, and storing the file acquired from the server in the file storage unit. And
[0020]
According to the present invention, in the network cache control method, the priority of the file stored in the file management table is 1 / (file size).
[0021]
In the network cache control method according to the present invention, the fault number management table stores the size of the file requested from the terminal and the number of faults in the cache, and the total size of the stored files is the file number. It has a function of deleting all stored information immediately before the capacity of the storage unit is exceeded.
[0022]
DETAILED DESCRIPTION OF THE INVENTION
Embodiments of the present invention will be described below in detail with reference to the drawings.
[0023]
[Embodiment 1]
FIG. 1 is a configuration explanatory
[0024]
The network cache device may be provided in a terminal that uses a file stored in the server via the network.
[0025]
The fault number management table 16 stores the file name, size, and number of faults of the cached file as one entry. An example of the fault number management table 16 is shown in FIG. When the file requested from the terminal 12 is in the
[0026]
The file management table 17 includes a file name, a priority, a last reference time, and a mark indicating that the number of faults stored in the fault number management table 16 has reached a predetermined number. Store as an entry. An example of the file management table 17 is shown in FIG. The last reference time is updated each time it is referenced. The priority may be determined in advance by the
[0027]
The
[0028]
5 is a flowchart showing the operations of the fault number management table 16, the file management table 17, and the
[0029]
Next, an operation example when the priority of the file is equal to 1 / (file size) is shown. In addition, the capacity of the
[0030]
Hereinafter, for the sake of brevity, the file management table 17 and the
[0031]
Assume that the file shown in FIG. 2 is requested. FIG. 3 shows the contents of the file management table 17 and the fault number management table 16 when a file is requested according to the sequence shown in the second line. The sequence number is given for convenience of explanation. The row of the fault number management table 16 shows the file name and the fault number of each entry. For example, A (2) means that the file name is A and the number of faults is 2. The time when the fault number management table 16 is cleared (all entries are deleted) is indicated by a vertical double line. Actually, it is determined whether or not the fault number management table 16 is cleared after the file is requested. For convenience, it is assumed that the fault number management table 16 is cleared immediately before the request that caused the clearing. A request from when the fault number management table 16 is cleared to a request immediately before being cleared next is called a phase. That is, the phase is a continuous partial sequence obtained by dividing the time series of requests issued from the terminal, and the longest partial sequence in which the total size of the requested different files does not exceed the capacity of the
[0032]
Initially, since the cache is empty, all requests up to the third are faulted, and all three files are stored in the file storage unit. Since these three requests all fault, the number of faults of the entry added to the fault number management table 16 is set to 1.
[0033]
When the file B is requested by the fourth request, when the entry of the file B is added to the fault number management table 16, the total size of each entry in the fault number management table 16 is the capacity of the file storage unit, Therefore, after the fault number management table 16 is cleared, an entry for the file B is added. Similarly, when the entry of file B is added to the file management table 17, the total size of the entries exceeds 10, so A having the lowest priority is deleted from files A, C, and D, and the entry of file B is deleted. Add.
[0034]
The fifth and sixth requests are the same as the fourth request.
[0035]
In the seventh request, the request to the file B faults, but since the B entry already exists in the fault number management table 16, the number of faults is increased by 1 to 2. Since the number of faults has reached 2, when making an entry B in the file management table 17, mark ( * )
[0036]
Since the request to the file A faults at the eighth request, in order to add the entry of the file A to the file management table 17, another entry must be deleted. In order of decreasing priority, B will be deleted. * ) Is attached, so delete it with LRU. In the LRU order, D is deleted because it has the oldest reference time. Since an entry for file A already exists in the fault number management table 16, the fault number is incremented by 1 to 2. Since the number of faults has reached 2, when making an entry A in the file management table 17, mark ( * )
[0037]
The ninth and tenth requests are requests for file B and file A. These are hits.
[0038]
A fault occurs in the eleventh request, and the process proceeds to the next phase.
[0039]
Since the 12th request is a request for the file E, it hits. However, in this phase, the request to the file E is the first time, and the entry does not exist in the fault number management table 16. Therefore, an entry for file E is added to the fault number management table 16. However, since no fault is made, the number of faults is set to zero.
[0040]
Within each phase, the total size of requested different files is always less than or equal to the capacity of the
[0041]
Also, in any phase, the marked file is never deleted by the LRU. The reason is as follows.
[0042]
That is, if the marked file Q is deleted by the LRU in order to put the file P into the
[0043]
Marked files are not deleted in order of low priority or LRU. Thus, the number of faults in each phase is at most twice for each file requested in that phase. Therefore, the faulty data capacity (fault amount) is at most twice the capacity of the
[0044]
When the number of faults stored in the fault number management table 16 reaches N (N is 1 or more), if the entry of the file management table 17 is marked, the number of faults in each phase is At most N times for each file requested in the phase. In terms of the fault amount, the capacity of the
[0045]
As described above, even if the mark is not invalidated when the fault number management table 16 is cleared, the file marked in the current phase is not deleted in the priority order or the LRU. The data capacity to fault in each phase (fault amount) is at most N times the capacity of the
[0046]
On the other hand, when only LRU is used, it is a continuous partial sequence obtained by dividing the time series of requests issued from the terminal 12, and the sum of the sizes of different files requested in the partial sequence is: In an arbitrary partial sequence that is at most the capacity of the
[0047]
That is, it is assumed that the file Q, which is faulted in the partial sequence of the request and placed in the
[0048]
Therefore, compared to the worst value of the number of faults and the amount of faults that can occur when using the LRU, the worst value of the number of faults and the amount of faults that can occur when using the method of the present invention is suppressed to N times at most. It is done. That is, by increasing the value of N, an operation close to cache control based only on priority can be performed, or by decreasing the value of N, an operation close to cache control using only LRU can be performed.
[0049]
[Embodiment 2]
For each file stored in the fault number management table 16, the total number of faults × size is calculated every time the fault number management table 16 is updated. This value is called the phase fault amount. As a result of updating the fault number management table 16 to process a request in an arbitrary phase, if the fault amount of the phase exceeds a predetermined value T, including the requested file at this time, In this phase, the entry in the file management table 17 is marked. In this way, after the phase fault amount exceeds T, each file faults at most once within the same phase, so the fault amount at each phase is at most (
[0050]
This will be described with reference to FIG. FIG. 4 shows the operation of the file management table 17 and the fault number management table 16 for T = 8 with respect to the same request sequence as FIG.
[0051]
Since the third request is a request for the file D, the entry of the file D is added to the fault number management table 16. As a result, since the total size of entries in the fault number management table 16 exceeds T, an entry for the file D is created and marked in the file management table 17.
[0052]
Just as in the first embodiment, the fault number management table 16 is cleared immediately before the fourth request.
[0053]
At the time of the sixth request, the entry of the file E is added to the fault number management table 16. As a result, the total size of the entries in the fault number management table 16 exceeds T. Therefore, an entry for the file E is created in the file management table 17 and a mark ( * ) Thereafter, the total size of entries in the fault number management table 16 exceeds T for requests in which faults have occurred until the phase is completed, so all newly added entries in the file management table 17 are marked. ( * )
[0054]
The same applies to the 16th and 17th requests.
[0055]
【The invention's effect】
As described above, according to the present invention, when a certain access pattern is assumed, a particularly effective cache control method is combined with the LRU method, so that the hit rate is higher than that of the LRU for the assumed access pattern. Therefore, it is possible to provide a network cache device and a network cache control method using cache control in which a predetermined value of the amount of faulting data is guaranteed even for access patterns other than the assumed access pattern.
[Brief description of the drawings]
FIG. 1 is an explanatory diagram showing a configuration of a first embodiment of the present invention.
FIG. 2 is an explanatory diagram showing an example of a file according to the present invention.
FIG. 3 is an explanatory diagram showing state transitions of a file management table and a fault count management table for a file request sequence according to
FIG. 4 is an explanatory diagram showing state transitions of a file management table and a fault count management table for a file request sequence according to
FIG. 5 is a flowchart showing operations of a fault number management table, a file management table, and a cache control unit according to
6 is a flowchart showing a fault number management table check operation in FIG. 5;
7 is a flowchart showing the file insertion operation of FIG.
FIG. 8 is an explanatory diagram showing an example of a fault number management table according to the present invention.
FIG. 9 is an explanatory diagram showing an example of a file management table according to the present invention.
[Explanation of symbols]
11 servers
12 terminals
13 network
14 Network cache device
15 File storage
16 Fault number management table
17 File management table
18 Cache control unit
Claims (10)
端末から出されたリクエストの時系列を、リクエストされた相異なるファイルのサイズの合計がファイル格納部の容量を越えない最長の部分列に分割するとともに、各部分列におけるキャッシュフォルト回数を、ファイルごとに記憶しておくフォルト数管理テーブルと、
ファイル格納部にキャッシュしたファイルごとに優先度を決める機能と、フォルト数管理テーブルに記憶されているファイルのフォルト数が所定の数に達したものにマークする機能を持ち、該キャッシュされたファイルごとに、該優先度と最終参照時刻に加え、マークされているかマークされていないかを区別する記号を記憶する、ファイル管理テーブルと、
端末からリクエストされたファイルがファイル格納部にない場合、該サーバーから獲得したファイルを該ファイル格納部に格納するためのスペースがあれば、該サーバーから獲得したファイルを該ファイル格納部に格納し、該ファイル格納部に該サーバーから獲得したファイルを格納するためのスペースがない場合は、該端末からリクエストされたファイルを格納するスペースをつくるために、該ファイル管理テーブルに記憶された情報をもとに、優先度の低い順にファイルを選択し、マークされていないファイルであれば削除し、マークされているファイルであれば、それ以後は、該マークされているファイルも含めた残りのファイルの中から最終参照時刻が古い順に該ファイル格納部からファイルを削除した上で、該サーバーから獲得したファイルをファイル格納部に格納するキャッシュ制御部、
を具備することを特徴とするネットワークキャッシュ装置。If the file is placed on the network connecting the server that stores and provides the file and the terminal that uses the file, and the file requested by the terminal is cached in the file storage unit, the file is sent to the request source and cached. Otherwise, the file is acquired from the server, sent to the request source, and cached in the file storage unit at the same time.
The time series of requests issued from the terminal is divided into the longest substrings in which the total size of the requested different files does not exceed the capacity of the file storage unit, and the number of cache faults in each substring is determined for each file. Fault number management table to be stored in
Each cached file has a function for determining the priority for each file cached in the file storage unit, and a function for marking the number of file faults stored in the fault number management table as having reached a predetermined number. In addition to the priority and the last reference time, a file management table for storing a symbol for distinguishing whether the mark is marked or not marked;
If the file requested from the terminal is not in the file storage unit, if there is a space for storing the file acquired from the server in the file storage unit, the file acquired from the server is stored in the file storage unit, If there is no space for storing the file acquired from the server in the file storage unit, the information stored in the file management table is used to create a space for storing the file requested from the terminal. Then, select the files in order of priority, delete them if they are not marked, and if they are marked, then in the remaining files including the marked file From the server after deleting files from the file storage section in order of the last reference time from the oldest Cache control unit for storing a file in the file storage unit,
A network cache device comprising:
端末から出されたリクエストの時系列を、リクエストされた相異なるファイルのサイズの合計がファイル格納部の容量を越えない最長の部分列に分割するとともに、各部分列におけるキャッシュフォルト回数を、ファイルごとに記憶しておくフォルト数管理テーブルと、
ファイル格納部にキャッシュしたファイルごとに優先度を決める機能と、フォルト数管理テーブルに記憶されているファイルのフォルト数が所定の数に達したものにマークする機能を持ち、該キャッシュされたファイルごとに、該優先度と最終参照時刻に加え、マークされているかマークされていないかを区別する記号を記憶する、ファイル管理テーブルと、
端末からリクエストされたファイルがファイル格納部にない場合、該サーバーから獲得したファイルを該ファイル格納部に格納するためのスペースがあれば、該サーバーから獲得したファイルを該ファイル格納部に格納し、該ファイル格納部に該サーバーから獲得したファイルを格納するためのスペースがない場合は、該端末からリクエストされたファイルを格納するスペースをつくるために、該ファイル管理テーブルに記憶された情報をもとに、優先度の低い順にファイルを選択し、マークされていないファイルであれば削除し、マークされているファイルであれば、それ以後は、該マークされているファイルも含めた残りのファイルの中から最終参照時刻が古い順に該ファイル格納部からファイルを削除した上で、該サーバーから獲得したファイルをファイル格納部に格納するキャッシュ制御部、
を具備することを特徴とするネットワークキャッシュ装置。If the file stored in the server is provided in a terminal that uses the file via the network, and the file requested by the terminal is cached in the file storage unit, the file is sent to the request source. In a network cache device that acquires a file from the server, sends it to the request source and caches it in the file storage unit,
The time series of requests issued from the terminal is divided into the longest substrings in which the total size of the requested different files does not exceed the capacity of the file storage unit, and the number of cache faults in each substring is determined for each file. Fault number management table to be stored in
Each cached file has a function for determining the priority for each file cached in the file storage unit, and a function for marking the number of file faults stored in the fault number management table as having reached a predetermined number. In addition to the priority and the last reference time, a file management table for storing a symbol for distinguishing whether the mark is marked or not marked;
If the file requested from the terminal is not in the file storage unit, if there is a space for storing the file acquired from the server in the file storage unit, the file acquired from the server is stored in the file storage unit, If there is no space for storing the file acquired from the server in the file storage unit, the information stored in the file management table is used to create a space for storing the file requested from the terminal. Then, select the files in order of priority, delete them if they are not marked, and if they are marked, then in the remaining files including the marked file From the server after deleting files from the file storage section in order of the last reference time from the oldest Cache control unit for storing a file in the file storage unit,
A network cache device comprising:
端末から出されたリクエストの時系列を、リクエストされた相異なるファイルのサイズの合計がファイル格納部の容量を越えない最長の部分列に分割するとともに、各部分列におけるキャッシュフォルト回数を、ファイルごとに記憶しておくフォルト数管理テーブルと、
ファイル格納部にキャッシュしたファイルごとに優先度を決める機能と、フォルト数管理テーブルに記憶されているファイルのサイズに各々のキャッシュフォルト回数をかけた値の合計が所定の値を越えたときに、最後にリクエストされたファイルを含め、それ以後、前記部分列が終了するまでの間に、リクエストされたファイルにマークする機能を持ち、該キャッシュされたファイルごとに、該優先度と最終参照時刻に加え、マークされているかマークされていないかを区別する記号を記憶する、ファイル管理テーブルと、
端末からリクエストされたファイルがファイル格納部にない場合、該サーバーから獲得したファイルを該ファイル格納部に格納するためのスペースがあれば、該サーバーから獲得したファイルを該ファイル格納部に格納し、該ファイル格納部に該サーバーから獲得したファイルを格納するためのスペースがない場合は、該端末からリクエストされたファイルを格納するスペースをつくるために、該ファイル管理テーブルに記憶された情報をもとに、優先度の低い順にファイルを選択し、マークされていないファイルであれば削除し、マークされているファイルであれば、それ以後は、該マークされているファイルも含めた残りのファイルの中から最終参照時刻が古い順に該ファイル格納部からファイルを削除した上で、該サーバーから獲得したファイルをファイル格納部に格納するキャッシュ制御部、
を具備することを特徴とするネットワークキャッシュ装置。If the file is placed on the network connecting the server that stores and provides the file and the terminal that uses the file, and the file requested by the terminal is cached in the file storage unit, the file is sent to the request source and cached. Otherwise, the file is acquired from the server, sent to the request source, and cached in the file storage unit at the same time.
The time series of requests issued from the terminal is divided into the longest substrings in which the total size of the requested different files does not exceed the capacity of the file storage unit, and the number of cache faults in each substring is determined for each file. Fault number management table to be stored in
When the total of the function that determines the priority for each file cached in the file storage unit and the number of times each cache fault is multiplied by the size of the file stored in the fault number management table exceeds a predetermined value, It has a function to mark the requested file from the last requested file to the end of the substring until the end of the subsequence, and for each cached file at the priority and last reference time In addition, a file management table that stores a symbol that distinguishes whether it is marked or not,
If the file requested from the terminal is not in the file storage unit, if there is a space for storing the file acquired from the server in the file storage unit, the file acquired from the server is stored in the file storage unit, If there is no space for storing the file acquired from the server in the file storage unit, the information stored in the file management table is used to create a space for storing the file requested from the terminal. Then, select the files in order of priority, delete them if they are not marked, and if they are marked, then in the remaining files including the marked file From the server after deleting files from the file storage section in order of the last reference time from the oldest Cache control unit for storing a file in the file storage unit,
A network cache device comprising:
端末から出されたリクエストの時系列を、リクエストされた相異なるファイルのサイズの合計がファイル格納部の容量を越えない最長の部分列に分割するとともに、各部分列におけるキャッシュフォルト回数を、ファイルごとに記憶しておくフォルト数管理テーブルと、
ファイル格納部にキャッシュしたファイルごとに優先度を決める機能と、フォルト数管理テーブルに記憶されているファイルのサイズに各々のキャッシュフォルト回数をかけた値の合計が所定の値を越えたときに、最後にリクエストされたファイルを含め、それ以後、前記部分列が終了するまでの間に、リクエストされたファイルにマークする機能を持ち、該キャッシュされたファイルごとに、該優先度と最終参照時刻に加え、マークされているかマークされていないかを区別する記号を記憶する、ファイル管理テーブルと、
端末からリクエストされたファイルがファイル格納部にない場合、該サーバーから獲得したファイルを該ファイル格納部に格納するためのスペースがあれば、該サーバーから獲得したファイルを該ファイル格納部に格納し、該ファイル格納部に該サーバーから獲得したファイルを格納するためのスペースがない場合は、該端末からリクエストされたファイルを格納するスペースをつくるために、該ファイル管理テーブルに記憶された情報をもとに、優先度の低い順にファイルを選択し、マークされていないファイルであれば削除し、マークされているファイルであれば、それ以後は、該マークされているファイルも含めた残りのファイルの中から最終参照時刻が古い順に該ファイル格納部からファイルを削除した上で、該サーバーから獲得したファイルをファイル格納部に格納するキャッシュ制御部、
を具備することを特徴とするネットワークキャッシュ装置。If the file stored in the server is provided in a terminal that uses the file via the network, and the file requested by the terminal is cached in the file storage unit, the file is sent to the request source. In a network cache device that acquires a file from the server, sends it to the request source and caches it in the file storage unit,
The time series of requests issued from the terminal is divided into the longest substrings in which the total size of the requested different files does not exceed the capacity of the file storage unit, and the number of cache faults in each substring is determined for each file. Fault number management table to be stored in
When the total of the function that determines the priority for each file cached in the file storage unit and the number of times each cache fault is multiplied by the size of the file stored in the fault number management table exceeds a predetermined value, It has a function to mark the requested file from the last requested file to the end of the substring until the end of the subsequence, and for each cached file at the priority and last reference time In addition, a file management table that stores a symbol that distinguishes whether it is marked or not,
If the file requested from the terminal is not in the file storage unit, if there is a space for storing the file acquired from the server in the file storage unit, the file acquired from the server is stored in the file storage unit, If there is no space for storing the file acquired from the server in the file storage unit, the information stored in the file management table is used to create a space for storing the file requested from the terminal. Then, select the files in order of priority, delete them if they are not marked, and if they are marked, then in the remaining files including the marked file From the server after deleting files from the file storage section in order of the last reference time from the oldest Cache control unit for storing a file in the file storage unit,
A network cache device comprising:
端末から出されたリクエストの時系列を、リクエストされた相異なるファイルのサイズの合計がファイル格納部の容量を越えない最長の部分列に分割するとともに、各部分列におけるキャッシュフォルト回数を、ファイルごとにフォルト数管理テーブルに記憶しておくフォルト数管理テーブル記憶ステップと、
ファイル格納部にキャッシュしたファイルごとに優先度を決める機能と、フォルト数管理テーブルに記憶されているファイルのフォルト数が所定の数に達したものにマークする機能を持つファイル管理テーブルに、該キャッシュされたファイルごとに、該優先度と最終参照時刻に加え、マークされているかマークされていないかを区別する記号を記憶する、ファイル管理テーブル記憶ステップと、
端末からリクエストされたファイルがファイル格納部にない場合、該サーバーから獲得したファイルを該ファイル格納部に格納するためのスペースがあれば、該サーバーから獲得したファイルを該ファイル格納部に格納し、該ファイル格納部に該サーバーから獲得したファイルを格納するためのスペースがない場合は、該端末からリクエストされたファイルを格納するスペースをつくるために、該ファイル管理テーブルに記憶された情報をもとに、優先度の低い順にファイルを選択し、マークされていないファイルであれば削除し、マークされているファイルであれば、それ以後は、該マークされているファイルも含めた残りのファイルの中から最終参照時刻が古い順に該ファイル格納部からファイルを削除した上で、該サーバーから獲得したファイルを該ファイル格納部に格納するキャッシュ制御ステップ、
を具備することを特徴とするネットワークキャッシュ制御手法。If the file is placed on the network connecting the server that stores and provides the file and the terminal that uses the file, and the file requested by the terminal is cached in the file storage unit, the file is sent to the request source and cached. If there is not, the file is acquired from the server, sent to the request source, and cached in the file storage unit at the same time.
The time series of requests issued from the terminal is divided into the longest substrings in which the total size of the requested different files does not exceed the capacity of the file storage unit, and the number of cache faults in each substring is determined for each file. Fault number management table storage step to store in the fault number management table,
The file management table has a function for determining the priority for each file cached in the file storage unit, and a function for marking the number of file faults stored in the fault number management table as having reached a predetermined number. A file management table storage step for storing, for each file, a symbol for distinguishing whether it is marked or not, in addition to the priority and the last reference time;
If the file requested from the terminal is not in the file storage unit, if there is a space for storing the file acquired from the server in the file storage unit, the file acquired from the server is stored in the file storage unit, If there is no space for storing the file acquired from the server in the file storage unit, the information stored in the file management table is used to create a space for storing the file requested from the terminal. Then, select the files in order of priority, delete them if they are not marked, and if they are marked, then in the remaining files including the marked file From the server after deleting files from the file storage section in order of the last reference time from the oldest Cache control step of storing the file in the file storage unit,
A network cache control method characterized by comprising:
端末から出されたリクエストの時系列を、リクエストされた相異なるファイルのサイズの合計がファイル格納部の容量を越えない最長の部分列に分割するとともに、各部分列におけるキャッシュフォルト回数を、ファイルごとにフォルト数管理テーブルに記憶しておくフォルト数管理テーブル記憶ステップと、
ファイル格納部にキャッシュしたファイルごとに優先度を決める機能と、フォルト数管理テーブルに記憶されているファイルのサイズに各々のキャッシュフォルト回数をかけた値の合計が所定の値を越えたときに、最後にリクエストされたファイルを含め、それ以後、前記部分列が終了するまでの間に、リクエストされたファイルにマークする機能を持つファイル管理テーブルに、該キャッシュされたファイルごとに、該優先度と最終参照時刻に加え、マークされているかマークされていないかを区別する記号を記憶する、ファイル管理テーブル記憶ステップと、
端末からリクエストされたファイルがファイル格納部にない場合、該サーバーから獲得したファイルを該ファイル格納部に格納するためのスペースがあれば、該サーバーから獲得したファイルを該ファイル格納部に格納し、該ファイル格納部に該サーバーから獲得したファイルを格納するためのスペースがない場合は、該端末からリクエストされたファイルを格納するスペースをつくるために、該ファイル管理テーブルに記憶された情報をもとに、優先度の低い順にファイルを選択し、マークされていないファイルであれば削除し、マークされているファイルであれば、それ以後は、該マークされているファイルも含めた残りのファイルの中から最終参照時刻が古い順に該ファイル格納部からファイルを削除した上で、該サーバーから獲得したファイルを該ファイル格納部に格納するキャッシュ制御ステップ、
を具備することを特徴とするネットワークキャッシュ制御手法。If the file is placed on the network connecting the server that stores and provides the file and the terminal that uses the file, and the file requested by the terminal is cached in the file storage unit, the file is sent to the request source and cached. If there is not, the file is acquired from the server, sent to the request source, and cached in the file storage unit at the same time.
The time series of requests issued from the terminal is divided into the longest substrings in which the total size of the requested different files does not exceed the capacity of the file storage unit, and the number of cache faults in each substring is determined for each file. Fault number management table storage step to store in the fault number management table,
When the total of the function that determines the priority for each file cached in the file storage unit and the number of times each cache fault is multiplied by the size of the file stored in the fault number management table exceeds a predetermined value, The file management table having a function of marking the requested file is included in the file management table having the function of marking the requested file after the last requested file including the last requested file. A file management table storage step for storing, in addition to the last reference time, a symbol for distinguishing whether it is marked or not;
If the file requested from the terminal is not in the file storage unit, if there is a space for storing the file acquired from the server in the file storage unit, the file acquired from the server is stored in the file storage unit, If there is no space for storing the file acquired from the server in the file storage unit, the information stored in the file management table is used to create a space for storing the file requested from the terminal. Then, select the files in order of priority, delete them if they are not marked, and if they are marked, then in the remaining files including the marked file From the server after deleting files from the file storage section in order of the last reference time from the oldest Cache control step of storing the file in the file storage unit,
A network cache control method characterized by comprising:
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000145399A JP3748195B2 (en) | 2000-05-17 | 2000-05-17 | Network cache device and network cache control method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000145399A JP3748195B2 (en) | 2000-05-17 | 2000-05-17 | Network cache device and network cache control method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001325142A JP2001325142A (en) | 2001-11-22 |
| JP3748195B2 true JP3748195B2 (en) | 2006-02-22 |
Family
ID=18651914
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000145399A Expired - Fee Related JP3748195B2 (en) | 2000-05-17 | 2000-05-17 | Network cache device and network cache control method |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3748195B2 (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6889302B2 (en) * | 2002-08-29 | 2005-05-03 | International Business Machines Corporation | Apparatus and method to maintain information in one or more virtual volume aggregates comprising a plurality of virtual volumes |
-
2000
- 2000-05-17 JP JP2000145399A patent/JP3748195B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001325142A (en) | 2001-11-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6754800B2 (en) | Methods and apparatus for implementing host-based object storage schemes | |
| US8661006B1 (en) | Data file management system and method for browsers | |
| JP4263672B2 (en) | System and method for managing cached objects | |
| US8239354B2 (en) | System and method for managing small-size files in an aggregated file system | |
| US5390318A (en) | Managing the fetching and replacement of cache entries associated with a file system | |
| EP1782212B1 (en) | System and method for maintaining objects in a lookup cache | |
| US7058763B2 (en) | File system for caching web proxies | |
| US8250081B2 (en) | Resource access filtering system and database structure for use therewith | |
| US7647417B1 (en) | Object cacheability with ICAP | |
| Arlitt et al. | Trace-driven simulation of document caching strategies for internet web servers | |
| US20050086437A1 (en) | Method and system for a cache replacement technique with adaptive skipping | |
| CN104794177B (en) | A kind of date storage method and device | |
| US20020032691A1 (en) | High performance efficient subsystem for data object storage | |
| CA2410747A1 (en) | System and method for saving browsed data | |
| US7577808B1 (en) | Efficient backup data retrieval | |
| US20020078087A1 (en) | Content indicator for accelerated detection of a changed web page | |
| US20070288719A1 (en) | Approach for de-fragmenting physical memory by grouping kernel pages together based on large pages | |
| DE102008048627A1 (en) | Allocating space in dedicated cache ways | |
| US7249219B1 (en) | Method and apparatus to improve buffer cache hit rate | |
| US6654856B2 (en) | System and method for managing storage space of a cache | |
| US7058766B2 (en) | Method and system of adaptive replacement cache with temporal filtering | |
| JP3748195B2 (en) | Network cache device and network cache control method | |
| JP3694226B2 (en) | Network cache device, network cache control method, and recording medium | |
| CN112424770A (en) | Ability to browse and randomly access large hierarchies at near constant times in stateless applications | |
| JP4179660B2 (en) | Hash value calculation method for character string, machine-readable recording medium storing program for realizing the method, hash value calculation device for character string, and information management device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20051122 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20051124 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091209 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101209 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101209 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111209 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111209 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121209 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121209 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131209 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |