(57)【要約】【課題】多層キャッシングシステムおよびその動作方法を提供すること。【解決手段】多層キャッシングシステムは、オペレーティングシステムまたはカーネルスペース（例えば、オペレーティングシステムによって管理されるメモリまたはオペレーティングシステムに割り当てられるメモリ）にて実行される第１のキャッシュと、アプリケーションスペースまたはユーザスペース（例えば、アプリケーションプログラムによって管理されるメモリまたはアプリケーションプログラムに割り当てられるメモリ）にて実行される第２のキャッシュとを含む。応答するデータを識別するための処理がほとんど必要とされないデータリクエストは、第１のキャッシュから供給され、応答するデータを識別するための処理がさらに必要とされるデータリクエストは、第２のキャッシュから供給される。【選択図】図４
2008159047.tif 000002
【特許請求の範囲】
【請求項１】
キャッシュシステムを動作させる方法であって、
データアイテムの第１のリクエストを受信することであって、該データアイテムの第１のバージョンが第１のメモリに常駐し、該データアイテムの第２のバージョンがキャッシュメモリに常駐し、該第２のバージョンが該第１のバージョンと比較して無効である、ことと、
該データアイテムの該第１のバージョンを該第１のメモリにリクエストすることと、
該データアイテムの該第１のリクエストに応答して該データアイテムの該第２のバージョンを供給することと
を包含する、方法。
【請求項２】
前記データアイテムの前記第１のバージョンを前記キャッシュメモリに格納することと、
前記第１のリクエスト後に受信された該データアイテムの第２のリクエストに応答して、該データアイテムの該第１のバージョンを該キャッシュメモリに供給することと
をさらに包含する、請求項１に記載の方法。
【請求項３】
前記データアイテムの第２のリクエストを受信することと、
該データアイテムの前記第１のバージョンが前記第１のメモリから受信されたか否かを決定することと、
前記第２のリクエストに応答して該データアイテムの前記第２のバージョンを供給することと
をさらに包含する、請求項１に記載の方法。
【請求項４】
前記第１のリクエストに応答して、前記データアイテムの前記第１のバージョンを前記第１のメモリから供給することが前記キャッシュシステムの性能に与え得るインパクトを決定することをさらに包含する、請求項１に記載の方法。
【請求項５】
前記データアイテムの特性を決定することと、
前記第１のリクエストに応答して、該データアイテムの該特性に依存して、前記第１のメモリからの該データアイテムの前記第１のバージョンおよび前記キャッシュメモリからの該データアイテムの第２のバージョンのうちの１つを供給することと
をさらに包含する、請求項１に記載の方法。
【請求項６】
前記特性は、前記データアイテムの経過時間、該データアイテムのサイズ、該データアイテムのタイプ、該データアイテムの人気、該データアイテムの前回のリクエストの最新性、前記第１のメモリから該データアイテムの前記第１のバージョンを検索するコスト、該データアイテムの無効性の最新性、該データアイテムの該第２のバージョンの無効性の度合いおよび該データアイテムの無効性の頻度のセットのうちの１つである、請求項５に記載の方法。
【請求項７】
前記第１のメモリがデータサーバのデータ格納デバイスの一部を含み、前記キャッシュメモリがキャッシュサーバのデータ格納デバイスの一部を含み、該データサーバが該キャッシュサーバとは異なる請求項１に記載の方法。
【請求項８】
前記第１のリクエストを受信することの前に、
前記キャッシュメモリにて前記データアイテムの前記第２のバージョンを受信することであって、該データアイテムの該第２のバージョンが該第１のメモリから複製された、ことと、
該第１のメモリに前回に格納された該データアイテムの該第２のバージョンを取り替えるために、該データアイテムの該第１のバージョンを該第１のメモリに格納することと、
該データアイテムの該第２のバージョンを無効化することと
さらにを包含する、請求項１に記載の方法。
【請求項９】
コンピュータによって実行されると、キャッシュシステムを動作させる方法を該コンピュータに実行させる命令を格納するコンピュータ読み出し可能な格納媒体であって、該方法は、
データアイテムの第１のリクエストを受信することであって、該データアイテムの第１のバージョンが第１のメモリに常駐し、該データアイテムの第２のバージョンがキャッシュメモリに常駐し、該第２のバージョンが該第１のバージョンと比較して無効である、ことと、
該データアイテムの該第１のバージョンを該第１のメモリにリクエストすることと、
該データアイテムの該第１のリクエストに応答して該データアイテムの該第２のバージョンを供給することと
を包含する、コンピュータ読み出し可能な格納媒体。
【請求項１０】
データリクエストに応答するようにキャッシュを動作させる方法であって、
キャッシュにてデータアイテムの第１のリクエストを受信することであって、該キャッシュが該データアイテムのキャッシュされたバージョンを格納するように構成されている、ことと、
該データアイテムの該キャッシュされたバージョンが無効であることを決定することと、
該データアイテムを格納するように構成されたサーバに該データアイテムをリクエストすることと、
該第１のリクエストに応答する前に該サーバから該データアイテムを待つことによってキャッシュ性能の所望のレベルが得られなくなる可能性があるか否かを決定することと、
該第１のリクエストに応答して該データアイテムの該キャッシュされたバージョンを供給することと
を包含する、方法。
【請求項１１】
前記キャッシュ性能の所望のレベルが前記第１のリクエストに対する応答時間を含む、請求項１０に記載の方法。
【請求項１２】
前記キャッシュ性能の所望のレベルが前記サーバによって処理されることを許可されるデータリクエストの数を含む、請求項１０に記載の方法。
【請求項１３】
前記キャッシュ性能の所望のレベルが前記サーバによって処理されることを許可されるリフレッシュリクエストの数を含む、請求項１０に記載の方法。
【請求項１４】
前記データアイテムの特性を識別することをさらに包含する、請求項１０に記載の方法。
【請求項１５】
前記特性は、前記データアイテムの人気および該データアイテムの前記キャッシュされたバージョンの無効レベルの１つを含む、請求項１４に記載の方法。
【請求項１６】
前記特性が、前記データアイテムの経過時間、該データアイテムのサイズ、該データアイテムのタイプおよび前記サーバから該データアイテムを検索するコストのうちの１つを含む、請求項１４に記載の方法。
【請求項１７】
前記リクエストすることの後に第２のリクエストを受信することと、
該第２のリクエストに応答して前記データアイテムの前記キャッシュされたバージョンを供給することと
をさらに包含する、請求項１０に記載の方法。
【請求項１８】
前記リクエストすることの後に第２のリクエストを受信することと、
該第２のリクエストを後回しにすることと
をさらに包含する、請求項１０に記載の方法。
【請求項１９】
前記サーバから前記データアイテムを受信することと、
該受信されたデータアイテムを前記キャッシュに格納することと、
該第２のリクエストに応答して該受信されたデータアイテムを戻すことと
をさらに包含する、請求項１８に記載の方法。
【請求項２０】
コンピュータによって実行されると、データリクエストに応答するようにキャッシュを動作させる方法を該コンピュータに実行させる命令を格納するコンピュータ読み出し可能な格納媒体であって、該方法は、
キャッシュにてデータアイテムの第１のリクエストを受信することであって、該キャッシュが該データアイテムのキャッシュされたバージョンを格納するように構成されている、ことと、
該データアイテムの該キャッシュされたバージョンが無効であることを決定することと、
該データアイテムを格納するように構成されたサーバに該データアイテムをリクエストすることと、
キャッシュ性能の所望のレベルが、該第１のリクエストに応答する前に該サーバから該データアイテムを待つことによって悪影響を受け得るか否かを決定することと、
該第１のリクエストに応答して該データアイテムの該キャッシュされたバージョンを供給することと
を包含する、コンピュータ読み出し可能な格納媒体。
【請求項２１】
データリクエストに応答するキャッシュシステムであって、
データサーバにて格納されたデータアイテムをキャッシュするように構成されたキャッシュメモリと、
該キャッシュされたデータアイテムが該データアイテムと比較して有効である否かを決定するように構成された有効性決定モジュールと、
該キャッシュされたデータアイテムが該データアイテムと比較して有効である場合、該データアイテムの第１のリクエストに応答して該キャッシュされたデータアイテムまたは該データアイテムのどちらを格納するかを決定するように構成されたプロセッサと
を含む、キャッシュシステム。
【請求項２２】
前記キャッシュメモリの前記キャッシュされたデータアイテムが前記第１のリクストに応答して戻される、請求項２１に記載のキャッシュシステム。
【請求項２３】
前記第１のリクエストが前記データサーバに転送され、該第１のリクエストが転送された後に受信される第２のリクエストが、前記キャッシュメモリから前記キャッシュされたデータアイテムを供給される、請求項２１に記載のキャッシュシステム。
【請求項２４】
前記データアイテムが前記データサーバから受信され、前記第１のリクエストの後に受信される第２のリクエストが前記キャッシュメモリから前記キャッシュされたデータアイテムを即時に供給される、請求項２１に記載のキャッシュシステム。
【請求項２５】
前記プロセッサが前記データアイテムの特性を試験するようにさらに構成されている、請求項２１に記載のキャッシュシステム。
【請求項２６】
前記特性は、前記データアイテムの人気、該キャッシュされたデータアイテムの無効レベル、該データアイテムの経過時間、該データアイテムのサイズ、該データアイテムのタイプおよび前記データサーバから該データアイテムを検索するコストのセットのうちの１つである、請求項２５に記載のキャッシュシステム。
【請求項２７】
前記プロセッサが前記キャッシュシステムの性能特性を試験するようにさらに構成されている、請求項２１に記載のキャッシュシステム。
【請求項２８】
前記性能特性は、前記第１のリクエストに対する所望の応答時間、前記キャッシングシステムでの開接続の数および前記データサーバによって処理されることを許可されたリクエストの数のセットのうちの１つである、請求項２７に記載のキャッシュシステム。
【請求項２９】
前記キャッシュシステムの性能レベルを測定する性能測定手段と、
前記測定された性能レベルをターゲット性能レベルと比較する比較手段と
をさらに含む、請求項２１に記載のキャッシュシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
（発明の背景）
本発明は、コンピュータシステムの分野に関する。より詳細には、本発明は、多層キャッシングシステムおよびある範囲の複雑さを有するデータリクエストを提供するシステムを動作する方法を提供する。
【０００２】
キャッシングシステムは、しばしばデータリクエストに対するより高速な応答を可能にするために利用され、特にリクエストされているデータが、比較的低速のデバイス（例えば、ディスク、テープ）上に格納されている場合に利用される。一般的にキャッシングシステムは、より高速なデバイス（例えばランダムアクセスメモリ）内にデータの全てまたはデータの一部を格納することによって性能を向上させ得る。
【０００３】
今日のコンピュータ環境では、ソフトウエアによって管理されたキャッシュは、オペレーティングシステム内部またはこのオペレーティングシステム上で動作するアプリケーションプログラムの一部として実現され得る。このオペレーティングシステム内部で実現されたキャッシュは、記憶デバイスへのより高速なアクセスを利用し得るが、アプリケーションプログラム内で実現されたキャッシュは、通常アプリケーションの符号化およびオペレーティングシステムによって付加されたオーバーヘッドを処理するためにより低速に動作する。しかし、アプリケーションプログラムの一部としてキャッシュを実現することはより容易であり得る。なぜなら、このオペレーティングシステムによって提供されたユーティリティおよび保護（例えば、メモリ管理）を利用し得るからである。これらの保護は、典型的にはオペレーティングシステムキャッシュに対して利用可能ではない。
【０００４】
従って、アプリケーションプログラムキャッシュは、比較的実現することが容易であり得るが、オペレーションシステムキャッシュと比較すると比較的性能が低い。他方、このオペレーティングシステムキャッシュは実現することがより困難であるが、より高い性能をもたらす。所望のレベルの性能および／または受容可能な設計努力に応じて、現在のキャッシングシステムは、これら２つのタイプのキャッシュの一方または他方を実現する傾向がある。
【０００５】
さらに、既存のキャッシングシステムは、リクエストされたデータが比較的静的であるか、および／または要求が多くない環境に最も適する。特に既存のシステムは、キャッシュされたデータが反復的または定期的に更新される必要がない場合、適切な利益を提供し得る。リクエストされたデータが本来動的である場合、特にデータリクエストの回数または頻度が高い場合、不幸にも、このようなシステムは、所望のレベルの性能を維持するには不適である。例えば、インターネット上において、多数のユーザは、ニュースストーリー、金融データ、マルチメディア表示等の形態の動的コンテンツを要求し、動的コンポーネントを含むカスタマイズされたユーザインターフェイスを介して要求し得る。特に、ユーザによってアクセスされた多くのサイトまたはウエブページは、定期的に更新された、または置換されたデータを含む。
【０００６】
インターネットのような高容量で動的な環境に対して、既存のキャッシングシステムは、安定したレベルの性能を維持するように設計されていない。逆に、このような環境は、一般的に一定のレベルのデータ品位を維持するように（典型的には、リクエストされたデータの最新のバージョンまたはより最近のバージョンを常に提供することを試みることによって）構成される。従って、キャッシュされるデータのマスターコピーまたはデータのバージョンが変更または置換される場合、より高速なキャッシュがユーザのリクエストを満たすために再度使用され得る前に、キャッシュ内のバージョンが更新または置換されなければならない。このキャッシュが更新されるまで、より低速なデバイス（例えば、マスターコピーが格納されるデバイス）からのこのデータに対するリクエストが満たされなければならない。トラフィックの量が多い期間、または大量のキャッシュされたデータが置換されなければならない場合、データリクエストは、キャッシュから供給されることができず、そしてウエブサイトが、このリクエストに応答するために、十分な数の代替的なより低速のデバイスを維持しない限り、ウエブサイトの性能は急激に低下し得る。
【０００７】
結果として、ウエブサイトオペレータが困難に直面する。オペレータは、トラフィックの予測されたレベルまたはピークのレベルを処理する十分な数のより低速なデバイスを利用し得、この場合キャッシングシステムは不要である。そうでなければ、オペレータは、恐らく性能をひどく低下させることを望んでいることになる。
【０００８】
従って、必要とされているのは、アプリケーションプログラムキャッシュに与えられた比較的容易な開発の利点を利用し、さらにオペレーティングシステムキャッシュによって提供される性能強化を利用し得るキャッシングシステムである。より詳細には、必要なことは、キャッシュの両方のタイプを組み込み、キャッシュの各タイプの適切なデータを格納するに十分フレキシブルである多層キャッシングシステムである。
【０００９】
また必要とされているのは、動的データおよび／または高容量のデータリクエストによって特徴付けられた環境におけるキャッシングシステムを動作するキャッシングシステムおよび方法であって、性能（例えば、データリクエストに対する応答時間）の所望のレベルが、キャッシングシステムの必要性を不要にすることなくピークまたは高トラフィック期間を実質的に維持し得るキャッシングシステムおよび方法である。さらに必要とされているのは、所望のレベルのシステム性能を促進させながら、データ整合の変更をできる限り小さく抑える性能ベースのキャッシングの方法である。
【発明の開示】
【課題を解決するための手段】
【００１０】
（要旨）
本発明の実施形態では、多層キャッシングシステムは、第１のキャッシュがカーネルまたはオペレーティングシステム空間において（例えば、オペレーティングシステムの一部として）実現され、第２のキャッシュは、ユーザまたはアプリケーションプログラム空間において（例えば、アプリケーションプログラムの一部として）実現される。
【００１１】
ある実施形態では、オペレーティングシステム空間キャッシュは、基礎的なデータリクエストまたは基本的なデータリクエスト（例えば、最小量の処理または調査を必要とするデータリクエスト）に応答して比較的簡単なデータを格納および提供するように設計される。より複雑なデータリクエストに応答するデータは、アプリケーションプログラム空間キャッシュに格納され得る。複雑なリクエストは、このリクエストに応答して提供すべきデータを識別するために調査されるべきデータリクエストに含まれる１以上のパラメータを要求し得る。
【００１２】
解析エンジンは、１組のガイドラインまたは規則の下で動作して、どのデータがどのタイプのキャッシュに格納されるべきかを決定し得、および／またはデータリクエストをあるキャッシュまたは他のキャッシュにルーティングし得る。従って、多層キャッシングシステムを動作するある方法では、データリクエストは、そのデータリクエストの複雑さに応じて、オペレーティングシステムキャッシュ空間またはアプリケーションプログラム空間キャッシュにルーティングされる。別の方法では、解析エンジンは、データアイテムが、大容量記憶媒体またはデータサーバから取り出されるかまたは受け取られる場合、どのキャッシュに格納されるべきかを決定する。データアイテムを格納するために、どのキャッシュを使用するかを決定する場合、解析エンジンは、例えば、データ取り出しに至るリクエスト（例えば、リクエストがどれくらい複雑か、データが複数のリクエストに応答するかどうか）を考慮し得、過去のリクエストに関する何らかの履歴解析を適用し得、システムアドミニストレータによって特定されたガイドラインまたはヒントを適用し得る。
【００１３】
多層キャッシングシステムのあるキャッシュに格納されたデータアイテムは、データアイテムの人気（例えば、どれくらいの間隔または頻度でデータアイテムがリクエストされるか）、年代、無効、またはいくつかの他の特徴に依存して異なるキャッシュに移動され得る。
【００１４】
本発明のある実施形態は、特にインターネット等のネットワーク環境において使用するために適している。ネットワーク環境において、ｈｔｔｐ（ハイパーテキスト転送プロトコル）または他のリクエストが、適切なデータが識別されそして提供され得る前に、分類されなければならない様々なヘッダ、クオリファイア、パラメータ、または他の表示と共に受信される。
【００１５】
本発明の代替的な実施形態では、データリクエストに対する応答時間、システムコンポーネント上に付与された負荷、オープン接続の数、またはいくつかのパラメータによって測定されるような、所望のレベルの性能を促進するような態様でデータをキャッシュするシステムおよび方法が提供される。この実施形態では、リクエストに応答して提供されたデータの整合は、リクエストされたデータの時間経過したバージョンを提供することによって、例えば、所望のレベルのパフォーマンスを促進するために変化することを可能にされ得る。
【００１６】
この代替的な実施形態では、無効化されたデータに対するリクエストがキャッシュサーバにおいて受信された場合、キャッシングシステムは、システムの現在の性能または所望された性能（例えば、オープン接続の数、平均応答時間または増分応答時間、スループット等）が、このリクエストが、データの更新されたバージョンまたは現在のバージョンを格納するデータサーバに伝えられることを可能にするかどうかをまず決定し得る。またこのリクエストに応答して行われる動作は、リクエストされたデータの人気（例えば、どれくらいの頻度またはどれくらい最近データがリクエストされているか）および／または無効レベル（例えば、どれくらい前にデータが無効化されたか、無効の度合い、データが最後に更新または置換されたのはいつか）等のファクタにも依存し得る。本発明の異なる実施形態は、それぞれ異なる動作ファクタに重きを置く。
【００１７】
例えば、キャッシュサーバ上で無効のデータに対するリクエストが、リクエストされたデータが人気があり、および／または無効が高いためにデータサーバに伝えられる場合、同じデータに対する以後のリクエストは、無効バージョンを用いてキャッシュサーバにおいて満たされ得る（新しいデータがデータサーバから受信されるまで）。逆に、人気が低くそして無効性は低いが、それでも無効であるデータがキャッシュサーバからリクエストされた場合、データの無効のバージョンがキャッシュサーバによって提供され得る。しかし、さらに、データの更新されたバージョンまたは置換バージョンに対するより優先度の低いリクエストが、より新しいデータを検索するためにデータサーバに伝えられ得る。
【００１８】
本発明の代替的な実施形態のある実現では、キャッシュされたデータアイテムの現在性または有効性は、所望のレベルのシステム性能（例えば、ユーザデータリクエストに対する目標応答時間）と、データアイテムの１つ以上の特徴（例えば、データアイテムがどれくらい人気があるか、データアイテムをリフレッシュするコスト、データアイテムがどれくらい価値があるか）と、実行され得る可能な速度またはリフレッシュの数等のファクタに依存し得る。これらのファクタに依存して、キャッシュメモリ（例えば、たとえキャッシュデータアイテムが無効であっても）あるいはデータサーバまたは他の一次格納デバイスから特定のデータリクエストが満たされ得る。
【発明を実施するための最良の形態】
【００１９】
（詳細な説明）
以下の説明は、当業者が本発明を作成および使用することを可能にするために提示され、本発明の特定の用途およびそれが要求する点において提供される。開示された実施形態に対する種々の改変は、当業者に容易に明らかになり、本明細書中で規定された包括的な原理は、本発明の精神および範囲から逸脱することなく他の実施形態および用途に適用され得る。従って、本発明は示された実施形態への限定を意図せず、本発明には、本明細書中で開示される原理および特徴と一致する最も広い範囲が与えられる。
【００２０】
本発明の本実施形態が例示的に実施されるプログラム環境は、汎用コンピュータまたは特殊デバイス（ハンドヘルドコンピュータ等）、あるいはデータをキャッシュすることなどの中心的な目的のために設計されたサーバを含む。このようなデバイス（例えば、プロセッサ、メモリ、データストレージデバイス、ディスプレイ）の詳細は、明瞭にするために省略され得る。
【００２１】
さらに、本発明の技術が種々の技術を用いて実現され得ることが理解されるべきである。例えば、本明細書中で説明される方法は、コンピュータシステム上で実行されるソフトウエアで実現され得るか、もしくはマイクロプロセッサまたは他の特別に設計されたアプリケーション特殊回路の組み合わせ、プログラム可能な論理デバイス、あるいはこれらの組み合わせのいずれかを利用するハードウエアにおいて実現され得る。特に、本明細書中で説明される方法は、搬送波、ディスクドライブ、またはコンピュータ読み出し可能媒体等の記憶媒体上に常駐する一連のコンピュータ実行可能な命令によって実現され得る。搬送波の例示的な形態は、ローカルネットワークまたは複数のアクセス可能なネットワーク（インターネット等）にわたってデジタルデータストリームを伝える、電気、電磁気または光信号の形態であり得る。
【００２２】
（はじめに）
現存するキャッシングシステムでは、キャッシュが、データリクエスタと、比較的遅い応答時間またはスループットを有するデータリクエストに応答するように構成された１つ以上のデバイス（例えば、データサーバ、ディスクドライブ、テープドライブ）との間に設けられ得る。このキャッシュは、より低速なデバイスからのデータを格納し、より大きな速度を有するユーザのリクエストに応答するように意図されている。しかし、データが比較的動的である環境において、キャッシュは、最新のデータを常駐させるために、データ更新またはデータ置換をリクエストし得る。一旦、キャッシュ上のデータアイテムが無効にされるか、またはそうでなければ、現在のキャッシングシステムでは時代遅れになる場合、およびデータが最後にリフレッシュされるまで、データに対するリクエストは、比較的低速なデバイスを通過しなければならず、従って応答時間および／またはスループットが低下する。従って、このようなキャッシングシステムは、データ整合を促進するが、性能は犠牲になる。多くの今日の電子環境では、高いレベルおよび／または持続可能なレベルのパフォーマンスが必要とされ、それによってこのタイプのシステムを不適にする。
【００２３】
従って、本発明のある実施形態では、所望のレベルの性能を促進するような態様でキャッシングシステムを動作させる方法が提供される。所望のレベルの性能は、応答時間、トラフィックのレベル、リクエストのスループット、オープンリクエストの数、またはいくつかの他の基準またはファクタによって測定され得る。データリクエストに応答して提供されたデータの整合は、所望の性能を実質的に維持するために変動が許され得る。より詳細には、システムの所望の性能および現在の性能、ならびに、リクエストを満たすためにどのような動作が行われようともその動作の可能性のある効果に応じて、このリクエストは、新しいデータまたは更新されたデータを待つように保持され得るか、比較的低速なデバイス（例えば、新しいデータ／更新されたデータが使用可能なデバイス）に伝えられ得るか、またはより古い（例えば無効な）データを提供され得る。種々の性能インジケータ（例えば応答時間、トラフィックレベル、処理電力）が、どの動作が行われるべきかを決定する際に考慮され得る。
【００２４】
リクエストされたデータの特性またはファクタもまた、リクエストをより低速なデバイスに伝えるか、データの無効のバージョンで応答するかを決定する際に考慮され得る。特にデータの人気および／または無効レベルが考慮され得る。データアイテムの人気は、データがアクセスまたはリクエストされた回数（または頻度）、どれくらい前にデータアイテムがキャッシュされたか、いつデータアイテムが最後にアクセスまたはリクエストされたか等のファクタに反映され得る。無効レベルは、どれくらい前にデータアイテムが最後に更新されたか（例えばデータの年代）、どれくらいの頻度または何回でそのデータが無効化されたか、どれくらい前にそのデータアイテムが最後に無効化されたか、無効の度合いまたはレベル（例えば、どれくらいの量のデータが時間経過したまたは時代遅れか等）の測定を含む。
【００２５】
オペレーティングシステムの一部として（例えば、カーネル空間に）実現された、ソフトウエアに管理されたキャッシュは、アプリケーションプログラムによって（例えばユーザ空間またはアプリケーション空間に）実現されたキャッシュよりもより高い性能（例えば、応答時間によって測定された）を有する傾向がある。しかし、オペレーティングシステムキャッシュの開発者は、オペレーティングシステムによってアプリケーションプログラムに提供されるメモリ管理保護および他のユーティリティを利用できない。このことは、オペレーティングシステムキャッシュの開発をより複雑に且つより困難にする。
【００２６】
従って、本発明の別の実施形態では、カーネル空間における少なくとも１つのキャッシュ、および、ユーザ空間またはアプリケーション空間における１つのキャッシュの内部接続された列を実現することによってキャッシュの両方のタイプの利益をもたらす多層システムが提供される。ユーザのデータリクエストの複雑さおよびそのリクエストに応答して提供されたデータの量に依存して、一方または他方のキャッシュからのデータでリクエストが満たされる。
【００２７】
本発明の１つ以上の実施形態は、ネットワーク環境（インターネット等）においての使用に特に適合しており、上記環境においては、リクエストされたデータは動的であり、および／または高容量のリクエストが受信され得る。例えば、定期的に更新または置換されるウエブサイト提供コンテンツは、ピークリクエストの期間中または大量のキャッシュされたデータが置換または更新される必要がある場合であっても、目標レベルの性能を維持するためにこの実施形態を実現し得る。
【００２８】
本発明の実施形態はインターネット等の広範囲にアクセス可能なネットワークおよびｈｔｔｐリクエストまたは他の形態のデータリクエストに応答して動的コンテンツを提供するという点において述べられるが、本発明はこのような実施形態の範囲に限定されない。本発明の他の実施形態は、キャッシュされるデータのタイプまたはそのデータがどれくらい動的であるかにかかわらず、所望のレベルのキャッシングパフォーマンスが必要とされる、文字通りのいかなる場所（例えば、ファイルシステム、データベース等）でも実質的に実現され得る。
【００２９】
（動的データの性能に基づくキャッシング）
図１は、本発明の一実施形態によるキャッシングシステムが実現され得る環境を示す。図１では、キャッシュサーバ１０２がネットワーク１０４とサーバ１０６のような１つ以上のサーバ（例えばウエブサーバ、コンテンツサーバ、データサーバ）との間に設けられる。ユーザ１０８ａ、１０８ｂ、１０８ｃはネットワーク１０４に接続される。ネットワーク１０４を介して、ユーザはサーバ１０６によって生成されたコンテンツ、および／またはサーバ１０６上に格納されたコンテンツに対するリクエストを提出する。この実施形態では、サーバ１０６によって提供されたデータは、テキスト、数値、マルチメディア、あるいは他のタイプおよび形態のネットワーク１０４を介したユーザへの伝送に適する情報を含み得、種々のプロトコルまたはフォーマット（例えば、ＨＴＴＰ、ＦＴＰ、ＨＴＭＬ、ＸＭＬ）の内の任意のものに添付され得る。
【００３０】
例示された実施形態では、キャッシュサーバ１０２は、サーバ１０６から分離しており、識別可能であるが、本発明の別の実施形態では、キャッシュサーバ１０２とキャッシュサーバ１０６のいずれか一方が他方を含むか、他方とともに配置され得る。さらに、データリクエストが受信され、および／または満たされる１つ以上の媒体は限定されず、従って、本システムは、有線技術および／または無線技術を用いる直接通信リンクまたは間接通信リンクを含み得る。
【００３１】
本実施形態の１つの実現では、キャッシュサーバ１０２およびサーバ１０６は、インターネットワールドワイドウエブサイトの一部として動作される。本実現では、１つ以上のユーザ１０８ａ、１０８ｂ、１０８ｃが、サーバ１０６によって提供される情報へのアクセスを望み、ブラウザまたは任意の他の適切なユーザインターフェイスを利用して、情報に対する適切なリクエストを提出し得る。
【００３２】
図１では、サーバ１０６上で生成されたデータまたは格納されたデータのいくつかのサブセットが、キャッシュサーバ１０２にコピーされ、キャッシュサーバ１０２からデータのサブセットがユーザリクエストに応答して迅速に提供され得る。従って、システムの動作の間、キャッシュサーバ１０２は、サーバ１０６を必要とすることなく、しばしばローカルキャッシュに格納されたデータを用いてユーザリクエストに応答するが、新しい情報または変更された情報に関してはコンテンツサーに頼り得る。動作の通常モードの間（例えば、キャッシュサーバ１０２上でキャッシュされたデータが、サーバ１０６上の対応するデータ同様最新のものである場合）、リクエストはキャッシュサーバによって提供される。リクエストがシステム性能および恐らく他のファクタ（例えば、データアイテムをリフレッシュするためのコスト、可能なリフレッシュ速度、データアイテムの人気または値）に影響を与えるかどうか、およびどのようにしてこれらに影響を与えるかに依存して、リクエストが、キャッシュデータが古い（例えば、時代遅れである、時間経過した、無効である）場合、サーバ１０６に送信され得る。
【００３３】
キャッシュサーバ１０２上の任意の特定のデータアイテムまたは他の情報は、有効または無効であると考えられ得る（および／または有効または無効であるとマーキングされ得る）。データアイテムのコピー元のサーバ１０６上のデータアイテムが変更も更新も置換もされてない場合、データアイテムは有効であると考えられ得る。サーバ１０６上の元のデータが変更または置換されている場合、データアイテムは無効であると考えられ得る。例示的には、データがサーバ１０６上で変更または置換される場合、通信は、キャッシュサーバに送信され得、対応する１つ以上のデータアイテムを無効にする。従って、キャッシュサーバがこのサーバから新しいデータを受信し、かつキャッシュする場合、データが無効であるか、あるいは、除去または置換されるべきであることが通知されるまで、キャッシュサーバは、ユーザリクエストに応答してそのデータを提供し続け得る。
【００３４】
キャッシュサーバ１０２は、一致するデータ（有効であれ無効であれ）がないリクエストを受信する場合、このリクエストはサーバ１０６に伝えられ得る。そして、リクエストされたデータが、逆にサーバから送信される場合、キャッシュサーバ１０２は、そのデータをローカルに格納し（そのデータを有効であるとマーキングし）、そのデータをリクエストしているユーザに転送する。
【００３５】
キャッシュサーバ１０２のオペレータまたはアドミニストレータは、１つ以上の性能特性、基準、またはインジケータを特定し、システムに対する性能の目標レベルを識別し得る。例えば、オペレータは、ユーザリクエストの９５％が２秒以内で提供されるべきであることを特定し得る。これは、ユーザリクエストの５％以下に対しては、応答を提供するのに２秒より長くかかることを意味する。別の例として、オペレータは、サーバ１０６が、１００を超えるリクエスト（例えば、データリクエスト、リフレッシュリクエスト）を一度に負担させるべきではないこと、またはそのサーバが１秒当たり１００ページより速いページ速度でコンテンツのページを生成するリクエストを負担させるべきではないことを特定し得る。本実施形態の異なる実現では、実質的に、性能の所望のまたは目標のレベルを決定するために測定可能な、またはキャッシュサーバ１０２によって適用され得る実質的に如何なる基準もが使用され得る。さらに、キャッシュサーバ１０２は、リクエストが実際に受信される前に、データアイテム（例えば無効アイテム）をリフレッシュすることによってデータリクエストの受領を予想し得る。
【００３６】
キャッシュサーバ１０２が、無効であるとマーキングされたデータに対するリクエストを受信する場合、キャッシュサーバは、このリクエストを無効の（例えば時間経過した）データで満たし得るか、そのデータをサーバ１０６に伝えるか、またはある別の実施形態では、そのリクエストを中断して有効なデータを待機する。そのリクエストをどのようにして処理するかを決定する際、キャッシュサーバ１０２は、トラフィックの量、データリクエストの数または頻度、無効のデータに対するリクエストの数または頻度、サーバ１０６の負荷レベル、サーバ１０６に伝えられるリクエストの応答時間、データリフレッシュまたはデータリクエストをサーバ１０６に提出するための可能な速度等のシステムの動作条件を考慮し得る。現在の条件が、所望のレベルの性能を示す特定のインジケータ、例えば、スループット（キャッシュサーバ１０２および／またはサーバ１０６による）、応答時間、サーバに対して所望される最大負荷または平均負荷等と比較され得る。
【００３７】
リクエストをサーバ１０６に送信するという決定またはリクエストが送信される優先度または緊急度は、データの特性（データの人気、年代、サイズ、タイプ、値、データをリフレッシュするコスト等）にも依存し得る。リクエストをデータサーバに伝えるかどうかについての決定、および／またはリクエストが転送される優先度もまた、そのデータがどれくらい無効であるか（例えば、どれくらいの量のデータが変更されたか、その変更がどれくらい急激なのか、どれくらい前にそのデータが無効であるとみなされたのか、そのデータが最後に更新されたのはいつか）に依存し得る。
【００３８】
従って、現在の動作条件が、サーバ１０６の性能および／またはデータ保証の特徴を含むことを可能にする場合、特に、そのリクエストが、そのデータの無効化後の、データに対する第１のリクエストまたは初期のリクエストである場合、無効化されたデータに対するリクエストがサーバ１０６に伝えられ得る。上述したように、サーバ１０６がリクエストされたデータを戻す場合、キャッシュサーバ１０２がデータを、リクエストしている１以上のユーザに転送し、さらに、他のリクエストを提供する際に使用するためにデータをキャッシュする。例示的には、１つのリクエストがサーバ１０６に伝えられた後に受信される、無効化されたデータに対する如何なる他のリクエストも、リクエストされたデータがサーバから受信されるまで保持され得る。しかし、任意の保留されたリクエストがあまりにも長い時間（例えば、所望の性能レベルが得られなくなる可能性があるほど）保持される場合、キャッシュサーバ１０２は、１つ以上の待ちリクエストを古い（すなわち無効化された）データで満たし得る。
【００３９】
満足させるためにデータサーバに伝えられたリクエストには、リクエストされたデータの人気、年代、無効、または他の特徴と整合する優先度のレベルが割り当てられ得る。しかし、リクエストの優先度は動的に変更され得る。
【００４０】
無効化されたデータに対する第１のリクエスト時の動作条件が、システム性能に有害な影響を与えることなしにはリクエストがサーバ１０６に送信されることができないか、またはリクエストされたデータが優先度サービスを保証するほど人気もなく無効でもないというものである場合、リクエストされたデータの以前のバージョンまたは古いバージョン（例えば無効化されたデータ）が、リクエストしているユーザに戻される。最新のデータは提供されないが、それにより所望のレベルのシステム性能が維持され得る。サーバ１０６から更新されたデータを受信するために必要な時間の量は、典型的にはかなり短いため、多くのユーザに時間経過したデータが提供されるというのは非常にまれである。特に、時間経過したデータは、トラフィックレベルが非常に速くおよび／または大量のキャッシュされたデータが無効にされた場合にのみ、または主に上記の場合に提供されることがあり得る。
【００４１】
図２は、本発明の１実施形態による図１のシステムにおいて、データを提供するための例示的な容量曲線を示す。この例示的実施形態では、キャッシュサーバ１０２は、１秒当たり１０００ページの速度でキャッシュされたコンテンツを提供することができるが、キャッシュサーバなしでは、サーバ１０６は、１秒当たり２００ページまでのコンテンツを提供することができる。
【００４２】
図２の曲線２００は３つの関連期間を示す。時刻ｔ０〜ｔ１の間、ユーザによってリクエストされたデータの有効なコピーまたは有効なバージョンはキャッシュサーバ１０２に格納され、リクエストに応えるために使用される。時刻ｔ１では、データが無効化され、キャッシュサーバが時刻ｔ２まで更新されない。時刻ｔ２の後、ユーザリクエストが新しいキャッシュデータに満たされる。
【００４３】
時刻ｔ１とｔ２との間、以前のキャッシングシステムは、無効化されたデータに対するリクエストがサーバ１０６に伝えられ、１秒当たり最大２００ページの速度で提供されるときに、容量（点線で示される）の著しい低下を経験し得る。しかし、本発明の実施形態によると、所望の性能を促進するために、無効化されたデータは、時刻ｔ１〜ｔ２の間、リクエストするユーザの一部または全てに提供され得る。しかし、少なくとも１つのリクエストが、新しいデータまたは更新されたデータを検索するためにサーバ１０６に伝えられ得る。
【００４４】
本発明の１つの代替の実施形態では、キャッシュされたデータが時刻ｔ１で無効にされる場合、キャッシュサーバが置換データに対するリクエストを開始し得るか、またはサーバ１０６が置換データを自発的に転送し得る。この代替の実施形態では、置換データがキャッシュされるまで、データをリクエストする全てのユーザが無効化されたデータを受信し得る。従ってこの代替的実施形態では、キャッシュサーバ１０２は、無効化されたデータに対するユーザリクエストを待つことなく更新される。
【００４５】
このように、本発明の例示的実施形態は、以前のキャッシングシステムにおいて経験された曲線２００の「谷」を完全にまたは部分的に取り除き得る。システム性能は、本実施形態の１つの実現における主要な目的であり得るが、提供されたデータの整合は無視されない。特に、本実施形態では、置換データがキャッシュサーバ１０２上でキャッシュされるとすぐにユーザリクエストに応答して、置換データが提供され得る。これは、所定の期間、時間経過したデータを提供し得る他のキャッシングシステムとは異なる。他のキャッシングシステムの場合、データ不整合を不必要に受ける。
【００４６】
キャッシュサーバ１０２は、所望のレベルの性能を促進するために、ユーザリクエストに対する応答速度、サーバ１０６に対する負荷、オープン接続の数、キャッシュされたデータアイテムの１つ以上の特性、および任意の他のパラメータをモニタリングし得る。時間経過したデータでリクエスト応答するのはいつか、または時間経過したデータでリクエストに応答すべきかどうかを決定するために監視されるべきパラメータが、システムアドミニストレータまたはオペレータによって特定され得、ならびに／あるいは、キャッシュサーバ１０２が、どの条件が反映されるのか、および／またはどの動作が低減された性能を引き起こすのかを決定するために学習アルゴリズムを適用し得る。次いで、これらの条件または動作が起こるとき、キャッシュサーバは、時間経過したデータを提供して、性能の低下を防ぎ得る。
【００４７】
図３は、本発明の本実施形態により、所望のレベルの性能を実質的に維持するキャッシングシステムを動作させる１つの方法を示す。示された方法は、キャッシュにコピーされキャッシュされたデータ（例えば、データサーバから）が更新または置換されるために、このキャッシュされたデータが時代遅れになったかまたは時間経過した電子機器環境において実現され得る。キャッシュされたデータは、実質的に任意の形態および任意のサイズであり得る。さらに、そして後のセクションで説明されるように、キャッシュサーバは、異なるタイプのデータリクエストを処理するために複数のキャッシュを実現し得る。
【００４８】
図３は、キャッシュされたデータアイテムをリフレッシュまたは更新する方法をも必然的に説明する。上述のように、キャッシュされたデータアイテムは、現在のデータリクエストまたは待機中のデータリクエストを満たすことの一部としてリフレッシュされ得るか、または未来のデータリクエストを予想して、将来のためにリフレッシュされ得る。
【００４９】
例示された手順の状態３００では、データサーバ上に格納されている、または格納されていたデータに対するリクエスト、および、キャッシュサーバにキャッシュされている、またはキャッシュされる予定のデータに対するリクエストが、キャッシュサーバにおいて受信される。キャッシュサーバは１つ以上のキャッシュメモリを有する。キャッシュメモリには、リクエストされたデータ、またはリクエストに応答しているが無効化された（例えば時代遅れになったか、または時間経過した）データのいずれか一方が格納される。データサーバに格納され、特にそのリクエスト応答するデータのバージョンが、現在無効のデータを置換または更新するために、キャッシュされたデータは無効であり得る。
【００５０】
状態３０２では、キャッシュサーバは、リクエストに応答するキャッシュされたデータが有効であるかどうかを決定する。例示的に、キャッシュデータが無効になる場合、キャッシュサーバはそのデータを無効としてマーキングする（例えば、データサーバによって指示された場合）。本発明の１実施形態では、データアイテムに対する次のリクエストの前に、動作条件が許容する場合、キャッシュサーバは無効化されたデータアイテムをリフレッシュし得る。キャッシュされたデータが有効である場合、状態３０４において、そのデータはリクエスタエンドに戻され、手順は終了する。
【００５１】
しかし、キャッシュされたデータが無効である場合、状態３０６において、キャッシュサーバは、応答データがデータサーバからリクエストされているかまたはデータサーバによって提供されているかを決定する。このようなデータは、以前に同じデータに対するユーザリクエストをデータサーバに伝えることによって、データサーバから既に要求されたかもしれない。あるいはキャッシュされたデータが無効化された場合、キャッシュサーバは、自動的に置換データまたは更新されたデータをリクエストしたかもしれない。あるいは、データサーバは、新しいデータを転送することを示したかもしれない。置換データが要求または開始されている場合、例示された手順は、そのデータを待機するため状態３１２にジャンプする。置換データが要求も開始もされていない場合、手順は状態３０８に進む。本発明の１つの代替の実施形態では、置換／更新されたデータがリクエストまたは開始された後、以後のリクエストがそのデータの無効のバージョンを用いて満たされ得る（置換／更新されたデータが受信されるまで）。
【００５２】
状態３０８では、キャッシュサーバは、データに対する現在のリクエストをデータサーバに転送するかどうかを決定する。このキャッシュサーバが、例えば、データサーバが、システム性能を所望のレベルよりも低いレベルまで低下させることも、低下させると脅かすこともなくリクエストを処理し得るかリクエストに応答し得ると決定すれば、このキャッシュサーバはこのリクエストを転送することを決定し得る。従って、性能の目標が２秒以内にユーザのリクエストの９５％に応えることである場合、このキャッシュサーバは、このリクエストが転送される場合、これらのガイドラインが違反される危険があるかどうかを決定し得る。所望の性能が脅かされるかどうかを決定する場合に、このキャッシュサーバは、データサーバ上で現在待機中のリクエストの数、リクエストが受信されているかまたはリクエストが受信された速度、そのキャッシュコンテンツの内どれくらいが無効であるか（そして更新／置換される必要があるか）、および／または他のファクタを考慮し得る。
【００５３】
従って、このキャッシュサーバが、データサーバ上の現在の負荷がタイミングよくリクエストに応えるには大きすぎるとみなす場合、たとえ現在のリクエストが新しいデータをリクエストする最初の機会であっても、このリクエストは転送され得ない。しかし、本実施形態の１つの実現では、新しいデータまたは更新されたデータがまだリクエストも開始もされていない状態で、特にリクエストが、応答するキャッシュデータが無効化された後に受信された最初のリクエスト（または初期のリクエスト）である場合、リクエストをデータサーバに転送することに対する偏見が存在し得る。
【００５４】
データサーバにリクエストを転送すべきかどうかを決定する際に考慮される他のファクタは、リクエストされたデータアイテムがどれくらい古いのか、どれくらい前にそのデータアイテムが無効化されたのか、どれくらいの量のデータアイテムが時代遅れであるか／時間経過しているか、データアイテムへの変更がどれくらい重要であるか、どれくらいの間隔または頻度でデータアイテムがリクエストまたはアクセスされるのか、いつデータアイテムが最後にアクセスされたか、データアイテムのサイズ、データアイテムを置換または更新するコスト等の、リクエストされたデータアイテムに関するファクタを含む。
【００５５】
従って、本発明の特定の実施形態では、いくつかのファクタの内のいずれかまたは全てが、いつ（またはどれくらいの間隔で）データアイテムがリフレッシュされるのか、および／または無効データが提供されるのではなく、データリクエストがデータサーバに伝えられるのはいつかを決定し得る。１つのファクタは、ユーザデータリクエストに対する所望の応答時間等の、所望のシステム性能または目標のシステム性能である。別のファクタは、データリクエストおよび／またはリフレッシュリクエストがデータサーバに提示され得る、可能な速度である。さらに別のファクタは、データアイテムの１つ以上の特徴（例えば、人気、無効、年代、サイズ、リフレッシュのためのコスト、値）に集中する。
【００５６】
リクエストをデータサーバに転送することが決定された場合、例示された手順が状態３１０に進む。それ以外の場合、この手順は、状態３０４に進み、このリクエストに応答して無効のキャッシュされたデータを戻す。キャッシュエントリが無効化され、サーバからデータを検索するために新しいデータ／更新されたデータに対する第１のリクエストまたは初期のリクエストが先に送られないという、この状況はまれな環境（例えば、多くのエントリが無効化された場合、および／または無効化されたエントリ（単数もしくは複数）に対する多数のユーザリクエストが受信された場合）においてのみ起こり得る。このような環境では、性能の安定なレベルが所望されるため、性能を犠牲にするよりも、時間経過したデータを戻すことが好ましくあり得る。さらに、この環境では、たとえ、現在のリクエストは転送されなくても、いくつかの無効化されたデータに対するリクエストが、依然として性能を考慮した場合に許される程度にデータサーバに転送される。無効化されたキャッシュエントリが置換または更新されるため、最終的にそしておそらく比較的短い期間内に、現在のリクエストに応答するデータがデータサーバから取り出され（例えば、データに対する後のリクエストが受信されそして転送されるときに）キャッシュされる。
【００５７】
状態３１０では、データリクエストがデータサーバに転送される。キャッシュサーバが応答時間またはデータサーバの他のいくつかの性能測定を測定するためにリクエストをトラックし得る。この情報は異なるリクエストが所望の性能を危険にさらすことなくデータサーバに転送され得るかどうかを決定する際に有用であり得る。
【００５８】
状態３１２では、キャッシュサーバは、データサーバからの新しいデータまたは更新されたデータを待機する。これらのデータが受け取られると、手順は状態３１６に進む。キャッシュサーバは新しいデータを待機している間に、性能統計をモニタ、収集、または生成し得る。さらに、本発明の１つの実施形態では、キャッシュサーバは、データの無効のバージョンを提供することによって新しいデータまたは更新されたデータを待機している間に、受信された同じデータに対するリクエストに応答し得る。
【００５９】
リクエストされたデータが受信されるまで、例示された手順は、状態３１４に進んで、新しいデータが利用可能でなくともこのリクエストに対して作用すべきであるかどうかを決定する。例えば、所望の性能レベルがユーザリクエストに応答するために必要な時間によって示され得る場合、キャッシュサーバは、リクエストが待機している時間の量をモニタリングし得る。性能の目標が待ち時間によって脅かされる場合、キャッシュサーバは状態３０４にジャンプし、時間経過したデータまたは無効のデータをリクエスタに戻す。次いでこの手順は、状態３０４を経て終了する。しかし、性能の目標／基準が許す限り、例示された手順は、状態３１２および３１４を繰り返し、現在のリクエストを満たすために新しいデータを待機する。
【００６０】
新しいデータまたは更新されたデータがデータサーバから受信されると、状態３１６において、このデータはキャッシュサーバのキャッシュメモリに格納される。キャッシュメモリは無効化されたデータを上書きしてもよいし、しなくてもよい。状態３１８では、新しいデータはリクエスタに戻され、この後、例示された手順が終了する。
【００６１】
図３は、キャッシングシステムにおいてデータリクエストに応答する１つの方法のみを示す。所望の性能レベルを維持するように努めつつ、データリクエストに応答する他の方法が、本発明の範囲を超えることなく例示された方法から引き出され得る。
【００６２】
本発明の特定の実施形態では、キャッシュサーバにおいて受信された無効のデータに対するリクエストが、無効のデータの人気、無効レベルおよび／またはいくつかの他の特徴に応じて分離され得る。第１のタイプの無効のデータ、例えば、人気があり無効が高いデータアイテム（無効は、例えば、どれくらい前にデータが無効になったか、無効の度合い、どれくらいの頻度でデータサーバがデータアイテムを無効としてマーキングしたのか、データの無効を順序化する通信の信頼性のレベルにより測定される）に高い優先度が割り当てられ、上記データアイテムがリクエストを満たすためにデータサーバに伝えられ得る。例示的に、置換データまたは更新されたデータが最初のリクエストに応答してデータサーバから受信されるまで、リクエストされたデータの無効のバージョンを用いて、同じデータアイテムに対する以後のリクエストがキャッシュサーバによって満たされる。
【００６３】
第１のタイプよりも人気がないデータアイテムのような、別のタイプ無効のデータに対するリクエストに対しては、リクエストされたデータの無効のバージョンがキャッシュサーバによって提供され得る。さらに、人気が少ないデータに対するより低い優先度のリクエストがデータサーバに転送され得る。リクエストに優先度を与え、リクエストに応える任意の方法が、データサーバによって適用され得るが、例示的には、本実施形態では、より高い優先度のレベルを有する全てのリクエストが、より低い優先度のレベルのリクエストが提供される前に提供される必要があり得る。リクエストの優先度は動的に改変可能であり得る。この人気の少ないデータに対する以後のリクエストに対して、データの更新されたバージョンまたはデータの無効のバージョンがキャッシュサーバによってデータサーバから受信されるまで、データの無効バージョンが提供される。
【００６４】
（多層キャッシング）
図４は、本発明の実施形態による多層キャッシュシステムを用いて構成されたコンピュータシステムを示す。例えば、コンピュータ４００は、図１に示されるキャッシュサーバと同様にネットワーク環境におけるキャッシュサーバであり得る。しかし本発明の範囲は、図４に示される特定の実施形態およびこのセクションで説明される実施形態に限定されない。
【００６５】
図４では、コンピュータシステム４００は、データリクエストをユーザ（例えばユーザ４３２）から受信するサーバであり、このリクエストは様々な形態をとり、ある複雑さの範囲を有する。従って、処理するために種々の程度の解析を必要とする。コンピュータ４００の１つの実現は、インターネットおよびワールドワイドウエブのような環境に合うように調整され得る。この環境の場合、コンピュータ４００は、ｈｔｔｐ（ハイパーテキスト転送プロトコル）リクエストを受信する。またコンピュータ４００は、この実現または代替的な実現において、ｆｔｐ（ファイル転送プロトコル）、ＮＦＳ（ネットワークファイルシステム）等の他の通信プロトコルに従ってフォーマットされたリクエストも受信する。
【００６６】
コンピュータ４００は、オペレーティングシステム（またはカーネル）空間４１０およびアプリケーションプログラム空間４２０を含み、これらの空間は、ユーザ空間とも考えられ得る。オペレーティングシステム空間４１０は、コンピュータ４００のメインメモリ（例えばＲＡＭ）の一部を含み得、このメモリは、オペレーティングシステム、あるいはオペレーティングシステムの１つ以上のコンポーネントまたはモジュールに割り当てられる。アプリケーションプログラム空間４２０は、アプリケーションまたはユーザプログラムあるいはこのようなプログラムのモジュールに割り当てられるメモリの領域（例えば仮想メモリ）であり得る。
【００６７】
この実施形態では、オペレーティングシステム空間４１０は、コンピュータ４００のオペレーティングシステムが実行される空間であり、オペレーティングシステムモジュールまたはコンポーネントが直接的またはほぼ直接的にコンピュータのハードウエア構成要素（例えば、ランダムアクセスメモリ、ディスクドライブ、入力／出力ポート）を操作し得る低レベルの動作を特徴とする。対照的に、アプリケーション空間４２０は、アプリケーションまたはユーザプログラムが実行される空間であり、これらのプログラムは、オペレーティングシステムによって提供されたユーティリティ、ドライバ、または手順によって入力／出力動作を実行し、ハードウエア動作を始動する。結果として、オペレーティングシステム空間４１０内部のキャッシュ４１２は、アプリケーション空間４２０のキャッシュ４２２よりもより高速かつより効率的に（例えば物理メモリへの直接読み出しを介して）コンピュータメモリにアクセスすることができる。
【００６８】
図４では、キャッシュ４１２は、データリクエストに応答して提供され得るデータまたはデータアイテムの１つのセットを格納すると同時にキャッシュ４２２は、データまたはデータアイテムの別のセットを格納する。
【００６９】
コンテンツ解析エンジン４２４は、例示された実施形態では、アプリケーションプログラム空間４２０において動作する。他の実施形態では、解析エンジンはオペレーティングシステム空間に配置されるかまたはこれら２つの空間で分割され得る。例示的には、コンテンツ解析エンジン４２４は、コンピュータ４００上でキャッシュするためにデータが受信される（例えば大容量記憶デバイスまたはデータサーバ４３０から）場合、データおよび／または他のコンテンツを解析する。この解析エンジンは、データの取り出しに至るデータとリクエストとの間の関係を調査して、例えばデータがそのリクエストのみに応答するか、複数のリクエスト（例えば、異なるタイプまたは異なる形態のリクエスト、あるいは、異なるパラメータまたはヘッダ値を有するリクエスト）に応答するかを決定して、データを識別する等のために、そのリクエストがどれくらいの処理または調査を必要としたかを決定する。要するに、コンテンツ解析エンジン４２４は、キャッシュされるべきデータがオペレーティングシステム空間４１２に格納されるべきか、アプリケーションプログラム空間キャッシュ４２２に格納されるべきかを決定するように構成される。上述のように、データリクエストおよびデータに関する種々の基準が、データアイテムがどのキャッシュに格納されるべきかを選択する場合に考慮され得る。
【００７０】
図４の実施形態では、データリクエストがコンピュータ４００においてユーザ４３２から受信される場合、キャッシュ４１２はリクエストを調査して、このリクエストに応答し得るかまたはこのリクエストに応答すべきかどうかを決定する。このリクエストに応答し得ないかまたはこのリクエストに応答すべきでない場合、このリクエストは、リクエストを満たすためにキャッシュ４２２に伝えられる。キャッシュ４２２がリクエストされた情報を有さない場合、このリクエストは、このリクエストされたデータを格納する別のエンティティに伝えられ得る。図４では、このリクエストはデータサーバ４３０等の別のコンピュータデバイスに伝えら得る。本発明の代替的な実施形態では、このリクエストは、ディスクドライブ、テープドライブ等の記憶デバイスに伝えられ得る。
【００７１】
キャッシュ４１２および／またはキャッシュ４２２は、コンテンツ解析エンジン４２４、システムアドミニストレータ、または他のソースからのガイドラインに基づいて特定のデータリクエストを処理するべきかどうかを決定し得る。従って、コンテンツ解析エンジン４２４は、特定のデータアイテムがキャッシュ４１２に格納されるべきであることを決定する場合、キャッシュ４１２は、所定のタイプのリクエストまたはフォーマットに応答して、データアイテムを提供するように構成され得る。
【００７２】
図４のキャッシュ４１２、４２２は、キャッシュを管理し実現するために必要なコンピュータ実行可能命令を含むと考慮される。しかし、本発明の代替的な実施形態では、キャッシュ４１２およびキャッシュ４２２に対して、別々のキャッシュ管理モジュールが、それぞれオペレーティングシステム空間４１０およびアプリケーションプログラム空間４２０に常駐し得る。
【００７３】
例示的には、コンピュータ４００のキャッシュ４１２、４２２に格納されたデータまたはデータアイテムが別の記憶デバイスまたは別のシステム（例えばデータサーバ４３０等）からコピーされるかまたは発生する。従って図４では、ユーザ４３２によってリクエストされたデータがデータサーバ４３０上で見出され得るが、サーバの応答時間（すなわち、リクエストをデータサーバに伝え、所望のデータを戻すために要する時間）は、リクエストされたデータがキャッシュされる場合、典型的にはコンピュータ４００の応答時間よりもはるかに長い。本発明の代替的な実施形態では、データの最終バージョン、最終的なバージョン、またはマスターバージョンがコンピュータ４００に接続された大容量記録デバイス（例えば、ディスク、テープ）上にあり得る。
【００７４】
コンピュータ４００がある範囲の形態および複雑さを有するデータリクエストを受信し得るため、本発明の１つの実施形態では、比較的簡単なデータリクエストに応答するデータがキャッシュ４１２に格納され得ると同時に、より複雑なリクエストに応答するデータがキャッシュ４２２に格納され得る。データアイテムが、簡単に応答するのか複雑なリクエストに応答するのかを決定することは、何らかの履歴解析、動作ガイドライン、またはヒント（例えば、システムアドミニストレータによって特定された）等を必要とし得る。例えば、ｈｔｔｐリクエストに応答して提供されたデータが、ヘッダ値（例えば、ユーザの言語または地理的位置を特定する）に依存する場合、このようなデータは、キャッシュ４１２の代わりにキャッシュ４２２に格納され得る。逆に、クオリファイア、ヘッダ、パラメータ、またはリクエストとともに含まれた他の表示に依存しないデータ、あるいは、複数のクオリファイアまたは他の表示に対して同じであるデータがキャッシュ４１２に格納され得る。
【００７５】
比較的複雑なデータリクエストがキャッシュ４２２によって処理されるため、キャッシュ４１２は、システムアドミニストレータまたはシステム開発者によって特定されたタイプのリクエストおよびデータを処理するに十分な「インテリジェンス」を有するのみの比較的簡単な状態に維持され得る。特に、複雑なリクエストがキャッシュ４２２によって調査されるため、キャッシュ４１２は、迅速に認識され処理され得る特定のタイプまたは特定の形態のリクエスト（例えば、ＵＲＬ（均一リソースロケータ）を識別することのみによって充足され得るｈｔｔｐリクエスト）のみ処理するように設計あるいは命令され得る。この場合、複雑なリクエストは、アプリケーション空間４２０において処理され、キャッシュ４２２は、メモリ管理、無効化、より大きな（仮想）メモリプールならびにオペレーティングシステムによって提供された他のユーティリティおよび機能を十分に利用し得る。
【００７６】
ｈｔｔｐリクエストは、発行ユーザのブラウザ、特徴セット、グラフィカル性能、セキュリティプロファイル、圧縮データを取り扱う機能等を特定するヘッダを含み得る。このようなリクエストは、例示的な実施形態において、オペレーティングシステムスペース４１０にてキャッシュ４１２の性能を遅くするのではなく、アプリケーションプログラムスペース４２０にて処理されるべきである。このようなリクエストが本実施形態においてアプリケーションプログラムスペース４２０にて処理されるべきである別の理由は、データアイテムのいくつかの変形がリクエストのヘッダ値の様々な置換に応答してキャッシングされる必要があり得ることである。有利には、キャッシュ４２２は、キャッシュ４２２が物理的なメモリではなく、仮想メモリを使用し得るためにキャッシュ４１２よりサイズが大きく、キャッシュ４１２より管理しやすい。これらの利点は、キャッシュ４２２の相対的に遅い性能を補うことに役に立つ。したがって、キャッシュ４２２は、同様のリクエストに対するデータを維持すること、および、複雑または可変なリクエストに応答することについて、キャッシュ４１２よりもより適している。
【００７７】
データアイテムがキャッシュ４１２に保存されるべきか、キャッシュ４２２に保存されるべきか否かを決定するときに考慮され得る他の要因は、アイテムの人気、アイテムの（相対的な）有効性または無効性、アイテムのサイズ、アイテムが含むデータのタイプ等である。頻繁に要求されるデータアイテム（例えば、ウェブサイトの複数のページ上に表示されたロゴ、オンラインカタログまたは価格リスト内の人気アイテムの価格等）は、キャッシュ４１２に保存され得る（特にサイズが幾分小さい場合）。人気のあまりないデータアイテムは、キャッシュ４２２に保存され得る。データアイテムの人気の測定は、データアイテムが何回アクセスされたか、データアイテムがいつ前回のアクセスをされたか、データアイテムがどのくらい前にキャッシングされたか等の特性を考慮することを含む。データアイテムの有効性は、データアイテムがいつ前回の更新をされたか、ＴＴＬパラメータ、データアイテムが無効とマーキングされたか否かおよびデータアイテムが何回無効とマーキングされたか（例えば、データサーバ４３０によって）、データアイテムがどのくらい前に前回無効化されたか、データアイテムを無効化しようと主張するメッセージの信頼性、無効性の重要度（例えば、データアイテムのうちのどのくらいの部分が無効であるか等）等の特性を考慮することによって測定され得る。本発明の１実施形態において、データアイテムは、１つのキャッシュから別のキャッシュに移動し得る。このような移動は、部分的には、データアイテムの人気、サイズ、有効性／無効性等の要因に起因し得る。
【００７８】
選択されたデータアイテムがキャッシュ４１２に配置されるべきか、キャッシュ４２２に配置されるべきかを決定する場合に考慮され得る別の要因は、データアイテムが相対的に動的か静的かである。データアイテムが相対的に静的である場合（すなわち、このデータアイテムが取り替えられるか、または更新される回数が他のアイテムより少ない場合）、データアイテムはキャッシュ４１２に保存される傾向が強くなり得る。規則正しく変化するデータアイテム（例えば、新しいまたは最新のニュースストーリー等）は、キャッシュ４２２に保存される傾向が強くなり得る。したがって、本発明の様々な実施形態において、上記の別の要因および／または本明細書中で特に列挙されていない他の要因の任意の組合せが、特定のデータがキャッシュ４１２に保存されるべきかまたはキャッシュ４２２に保存されるべきかを決定するために用いられ得る。これらの決定は、図４の実施形態のコンテンツ解析エンジン４２４によって為され得る。
【００７９】
しかし、本発明の別の実施形態において、システムアドミニストレータは、リクエストは、どのように処理されるべきか、および／または、どのようなデータアイテムまたはどのようなタイプのデータアイテムがキャッシュ４１２およびキャッシュ４２２の各々での保存に適しているかについて、のヒントを提供し得る。これらのヒントは、コンテンツ解析エンジン４２４の動作を取り替え、または、補足し得る。例えば、アドミニストレータは、特定の形式を有するデータリクエストが、リクエストに提供された特定値に依存して多数の異なる言語で供給される必要があり得ることを特定し得る。次いで、多層キャッシングシステムは、このようなリクエストをアプリケーションプログラムスペースのキャッシュに向かわせ、このリクエストに応答して検索されたデータは、オペレーティングシステムスペースのキャッシュではなく、アプリケーションプログラムスペースのキャッシュに保存される。逆に、アドミニストレータが、所定のデータリクエストまたは所定のタイプのリクエストに対して、同じデータアイテムがヘッダに組み込まれた情報に無関係に供給されると特定する場合、応答するデータアイテムは、オペレーティングシステムスペースキャッシュに保存され得る。
【００８０】
本発明の１つの代替的な実施形態において、キャッシングシステムは、時間の経過と共にリクエストを解析し得、これらのリクエストに応答して供給されたデータにこれらのリクエストを相関させ得、特定のデータアイテムが複数の個々のリクエストに応答するか、これらのリクエストのタイプに応答するかについて決定し得る。
【００８１】
本発明の１実施形態において、アドミニストレータガイドラインは、ウェブサイトの一部を識別し、かつ、識別された一部のユーザリクエストに応答して供給すべきデータを決定するためにキャッシングシステムが使用すべき情報を特定する。例えば、ウェブサイトコンポーネントが階層的に（例えば、ツリー構造に）配置される箇所では、ウェブサイトの識別可能領域は、多数のページを包含する。アドミニストレータは、異なる領域について、どのタイプの情報が、供給すべき正しいデータを決定するために必要とされるかを特定し得る。必要な情報とは、例えばユーザに見せる価格単位が何かを決定するためには、ユーザの地理的な位置であり得、どのような視覚的なコンポーネントが供給されたページに含まれ得るかを決定するためには、ユーザのブラウザまたはグラフィカル能力であり得る。上述したように、変化する評価基準に対する特定のユーザ値はデータリクエストの一部として特定され得る。または、この特定のユーザ値は、ユーザのコンピュータシステムのクッキーとして保存され得、コンピュータ４００、データサーバ４３０またはコンピューティング環境のいくつかの他の要素によって検索され得る。例えば、キャッシュ４２２は、ユーザのデータリクエストが受信されるときにユーザからクッキーを引き出し得る。
【００８２】
本発明の例示的な実施形態において、データアイテムがキャッシュ４１２に保存されるか、キャッシュ４２２に保存されるかを決定する規則またはガイドラインは動的である。それゆえ、この規則またはこのガイドラインは、多層キャッシングシステムの動作を変更させるために、更新され得るか、または取り替えられ得る。
【００８３】
本発明の別の代替的な実施形態において、データアイテムが保存されるキャッシュは、データアイテムに組み込まれた情報に依存し得る。例えば、ｈｔｔｐ規格のバージョン１．１において、ウェブページはＶＡＲＹヘッダを含み得、この場合、ウェブページのコンテンツは、特定の評価基準（例えば、言語、ブラウザ、地理的な位置）に依存して変わる。この代替的な実施形態においては、このようなデータアイテムをキャッシュ４１２よりキャッシュ４２２に保存する方がより効率が良くなり得る。
【００８４】
オペレーティングシステムスペースのキャッシュ４１２は、アプリケーションスペースのキャッシュ４２２より少ないデータを維持するように構成され得るが、データリクエストの配信に依存して、コンピュータ４００にて受信された大きな割合のデータリクエストに応答するデータさえも維持し得る。例えば、キャッシュ４１２がキャッシュ４２２のほんの一部のサイズに過ぎない場合でさえ、データリクエストに関する履歴情報（例えば、データリクエストに応答して供給されるデータを含む）が取り込まれ、最も人気の高いアイテムを決定するために適用されるなら、キャッシュ４１２が大部分のデータリクエストに応答できるようになり得る。
【００８５】
コンピュータ４００は、キャッシュ４１２および／またはキャッシュ４２２が無効（例えば、時間が経過して無用になってしまった）であるか否か／キャッシュ４１２および／またはキャッシュ４２２が無効であるのはいつかを決定するために、データサーバ４３０等の別のコンピュータシステムと通信し得る。または、データサーバは、キャッシングされたデータが無効であるときをコンピュータ４００に自動的に知らせ得る。
【００８６】
キャッシュ４１２は、オペレーティングシステムにロード可能であるモジュールとして実行され得る。Ｕｎｉｘ（登録商標）ベースのオペレーティングシステムにおいて、例えば、キャッシュ４１２は、ＳＴＲＥＡＭＳモジュールを用いて実行され得る。または、代替として、キャッシュ４１２は、オペレーティングシステムに構築され得る。
【００８７】
図４の多層キャッシングシステムは２つのキャッシュだけを示しているが、本発明の代替的な実施形態において、さらなる層が追加され、実行され得る。例えば、より低い層は、ハードウェアデバイス（例えば、ネットワークインターフェース回路の一部または入力／出力ポートとして）にて、実行され得る。別の例としては、キャッシュは、オペレーティングスペース４１０またはアプリケーションプログラムスペース４２０のいずれかにおいて複数のキャッシュを実行することによって、キャッシュ４１２とキャッシュ４２２との間に挿入され得る。さらに、本発明の実施形態による多層キャッシングシステムのキャッシュは、異なる層のプロトコルスタック内で実行され得るか、異なる層のプロトコルスタックに関連づけられ得る。
【００８８】
図５Ａおよび図５Ｂは、本発明の１実施形態による多層キャッシングシステムのデータリクエストを受信し、このデータリクエストに応答する１手順を示す。本実施形態において、オペレーティングガイドラインは、オペレーティングシステム内で（または、オペレーティングシステムにロード可能なモジュールとして）実行される第１のキャッシュ（例えば、キャッシュ１）、および、アプリケーションプログラムまたはユーザプログラムの一部として、またはアプリケーションプログラムまたはユーザプログラムに関連して、実行される第２のキャッシュ（例えば、キャッシュ２）に対して特定される。例示的には、このガイドラインは、要求されたデータが最も配置されていそうな位置に依存して、データリクエストがキャッシュ１によって処理されるべきか、キャッシュ２によって処理すされるべきかを決定するために用いられる。例えば、このガイドラインは、応答するデータがキャッシュ１に保存される傾向にあるかまたは傾向にないリクエストのフォーマットまたはタイプを識別し得るか、または特定し得る。
【００８９】
キャッシュ１、またはキャッシュ１のコンテンツは、キャッシュ１のコンテンツがオペレーティングシステムによって（またはオペレーティングシステムの指示下で）挿入され、除去されるという点において、オペレーティングシステムによって管理されると考慮され得る。キャッシュ２、またはキャッシュ２のコンテンツは、アプリケーションプログラムまたはユーザプログラムによって管理されると考慮され得る。
【００９０】
状態５００において、データリクエストは、ユーザからキャッシュ１にて受信される。例示的に、このリクエストは、インターネットまたはイントラネット等のウェブベースの環境に供給されるコンテンツ用である。
【００９１】
状態５０２において、キャッシュ１（またはキャッシュ１に対応する管理モジュール）は、このリクエストを試験する。例えば、キャッシュ１は、リクエストのタイプを識別し得る、および／または、このリクエストの１つ以上のヘッダまたはこのリクエストの他のコンポーネントを検索し得る。
【００９２】
キャッシュ５０４において、キャッシュ１は、キャッシュ２にこのリクエストを伝えるか、このリクエストを満たすことを試みるかを決定する。特に、上述されたように、本発明の例示的な実施形態において、キャッシュが、所与のデータリクエストがキャッシュ１によって処理されるべきか、キャッシュ２によって処理されるべきかを決定できるようにガイドラインが提供されている。特に、キャッシュ１は、リクエストの特性を明らかにするか、または、他の場合には、要求されたデータがキャッシュ１に常駐する傾向にあるか否かを決定するために、上述のガイドラインを適用し得る。例えば、このガイドラインは、全てのｆｔｐリクエストがキャッシュ２に伝えられる（または、データサーバ等の別のデバイスに直接的に伝えられる）と規定し得る、または、特定のＵＲＬに対する全てのリクエスト（場合によっては、任意のリクエストヘッダと無関係に）にキャッシュ１に保存される特定のデータアイテムが供給されるべきであると規定し得る。したがって、リクエストのタイプまたはリクエストの基本コンポーネントを識別するだけで、キャッシュ１は、このリクエストを取り扱う方法を決定できる。
【００９３】
本実施形態において、明らかな規則が、迅速で、正確なリクエストのルーティングを可能にするために提供される。しかし、代替的な実施形態において、キャッシュ１は、受信されたリクエストを満たそうとするだけであり得、キャッシュ１が要求されたデータを有していない場合、このリクエストをキャッシュ２に伝え得る。この代替的な実施形態は、特に、１セットのガイドラインを適用してリクエストがどこで処理されるかを決定するために必要な時間より短時間で探索され得る比較的小さなオペレーティングシステムキャッシュの使用に適し得る。
【００９４】
状態５０４において、ガイドラインが、リクエストが比較的に複雑である（したがって、さらなる構文解析または解析を必要とする）か、または、リクエストに応答するために必要なデータがリクエストの１つ以上のパラメータに依存し得ることを示す場合に、キャッシュ１は、状態５０６において、このリクエストをキャッシュ２に伝える。他の場合、例示された手順は状態５１４に進む。
【００９５】
状態５０６においてリクエストがキャッシュ２に伝えられた後、状態５０８において、キャッシュ２は、リクエストを構文解析するか、またはさらにリクエストを解析して（例えば、全てのヘッダまたは他の区別情報を検索するために）、リクエストに応答して供給されるべきデータを決定または識別する。
【００９６】
状態５１０において、キャッシュ２は、キャッシュ２が供給されるべきデータを含むか否かを決定する。キャッシュ２がデータを含む場合、状態５１２において、このデータは供給され、この手順が終了する。他の場合、この手順は状態５２０に進む。
【００９７】
状態５１４において、キャッシュ１は、リクエストに応答して供給されるべきデータを保存するか否かを決定する。キャッシュ１がデータを保存する場合、状態５１２において、このデータが供給され、この手順が終了する。他の場合、この手順は状態５２０に進む。
【００９８】
状態５２０において、リクエストが、キャッシュ１またはキャッシュ２のいずれかに現時点で格納されるデータで満たされ得ず、この結果、リクエストは、データが位置する別のデバイス（例えば、データサーバ）に伝えられる。
【００９９】
状態５２２において、要求されたデータがデータサーバによって戻され、この結果、このデータは、キャッシングされ得、要求しているユーザに提供され得る。したがって、状態５２４において、このデータは、キャッシュ１またはキャッシュ２のいずれかに保存される。例示的には、このデータは、ガイドラインの下で、リクエストに対する主な責任を有すると決定されたいずれかのキャッシュに供給される。本発明の代替的な実施形態において、ガイドラインの代わりに、または、ガイドラインに加えて、履歴情報が収集され得、この履歴情報は、いずれのキャッシュに、データサーバから受信されたデータが保存されるべきかを決定するために解析され得る。
【０１００】
状態５２６において、データがユーザに供給され、例示的な手順が終わる。
【０１０１】
図５Ａおよび図５Ｂは、本発明の１実施形態によって多層キャッシングシステムを動作させる１つの手順のみを説明する。他の手順は、本発明の先述の説明から導かれ得る。例えば、いずれのキャッシュがリクエストを取り扱うべきかを（いずれのキャッシュが要求されたデータを保存する傾向が強いかに基づいて）決定するために１セットのガイドラインを適用する代わりに、代替的な実施形態において、キャッシュが逐次的に動作する。したがって、キャッシュ１は、リクエストを受信し、リクエストを満たそうと試み、キャッシュ１が要求されたデータを保存していない場合には、このリクエストをキャッシュ２に伝えるに過ぎない。別の代替的な実施形態において、１つ以上のキャッシュが、時間の経過と共に、受信される（複数または特定の）リクエストのタイプおよびリクエストに応答して供給されるデータを解析し得る。学習アルゴリズムは、最も頻繁に要求されるデータをキャッシュ１にキャッシングするか、または、いくつかの異なるリクエストあるいは異なるタイプのリクエストに対して供給され得るデータをキャッシュ１に保存するために適用され得る。
【０１０２】
本発明の実施形態の上述の説明は、例示および説明のためだけに提示されてきた。この説明は、排他的であることを意図されておらず、または本発明を開示された形式に限定することを意図されていない。したがって、上述の開示は、本発明を限定するように意図されていない。本発明の範囲は、特許請求の範囲によって規定される。
【図面の簡単な説明】
【０１０３】
【図１】図１は、本発明の実施形態によるデータをキャッシングするための電子環境を示す図である。
【図２】図２は、本発明の実施形態による性能能力の安定なレベルの維持を示す図である。
【図３】図３は、本発明の実施形態によるキャッシングシステムの動作を示すフローチャートである。
【図４】図４は、本発明の実施形態によるキャッシュの多層システムを示すブロック図である。
【図５Ａ】図５Ａは、本発明の実施形態による多層キャッシングシステムにおけるデータリクエストの受信およびデータリクエストに対する応答のための手順を示す。
【図５Ｂ】図５Ｂは、本発明の実施形態による多層キャッシングシステムにおけるデータリクエストの受信およびデータリクエストに対する応答のための手順を示す。
【図１】
2008159047.tif 000003
【図２】
2008159047.tif 000004
【図３】
2008159047.tif 000005
【図４】
2008159047.tif 000006
【図５Ａ】
2008159047.tif 000007
【図５Ｂ】
2008159047.tif 000008