JP3575428B2 - インテリジェントネットワーク帯域幅およびシステムリソースを使用するための方法および装置 - Google Patents
インテリジェントネットワーク帯域幅およびシステムリソースを使用するための方法および装置 Download PDFInfo
- Publication number
- JP3575428B2 JP3575428B2 JP2001019771A JP2001019771A JP3575428B2 JP 3575428 B2 JP3575428 B2 JP 3575428B2 JP 2001019771 A JP2001019771 A JP 2001019771A JP 2001019771 A JP2001019771 A JP 2001019771A JP 3575428 B2 JP3575428 B2 JP 3575428B2
- Authority
- JP
- Japan
- Prior art keywords
- content
- bandwidth
- time
- fetch
- connections
- 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
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/957—Browsing optimisation, e.g. caching or content distillation
- G06F16/9574—Browsing optimisation, e.g. caching or content distillation of access to content, e.g. by caching
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/953—Organization of data
- Y10S707/959—Network
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Information Transfer Between Computers (AREA)
Description
【発明の属する技術分野】
本発明は、概して、コンテンツ配信(content delivery)ネットワークに関し、好ましい実施形態の場合には、Webコンテンツを効率的に取り出し、またリフレッシュする目的で、インテリジェントネットワーク帯域幅およびシステムリソースを使用するための方法および装置に関する。
【0002】
【従来の技術】
Webの性能は、コンテンツプロバイダの間の分化の最も重要なポイントである。主要なWebサイトが混乱状態にあり、また低速状態にあることが、大量のWebトラフィックを克服しようとしている各社が当面している困難な問題を証明している。インターネットのバックボーン技術が発達するにつれて、ネットワーク帯域幅を改善し、Webコンテンツの検索時間を短縮するために、サービス管理の品質のような多くの革新が使用されてきた。しかし、インフラストラクチャに関するこれらの改善は、インターネット内の任意のある点で発生するトラフィックの問題を解決することはできない。例えば、図1の場合には、日本のネットワーク12内のエンドユーザー10が、米国のネットワーク16内のコンテンツプロバイダオリジナルWebサイト14内の、あるページにアクセスしようとしている。この要求は、コンテンツプロバイダオリジナルWebサイト14に届く前に、いくつかのインターネットサービスプロバイダ(ISP)のゲートウェイ18、20および22を通過する。ゲートウェイのボトルネックと、ユーザーとコンテンツプロバイダオリジナルWebサイト14との間のインターネット経路に沿った他の遅延要因とのために、ゲートウェイのエンドユーザー側で、プロキシサーバーを利用するコンテンツ取出し/リフレッシュ方法を使用すれば、応答時間を短縮することができる。
【0003】
図2は、複数の非特定Webサイト28および30に接続しているキャッシュシステム26を含む、通常のWebコンテンツ配信およびキャッシュスキーム24である。キャッシュシステム26は、プロキシサーバーまたはキャッシュサーバー32およびキャッシュ34からなる。別の方法としては、図2のキャッシュシステム26の代わりに、コンテンツ配信サービスプロバイダとすでに加入者契約を結んでいるWebサイトに接続しているコンテンツ配信サービスプロバイダおよびミラーサイトを利用することができる。これら加入者Webサイトは、監視するためのコンテンツ配信サービスプロバイダにコンテンツを配信する(delivery)が、コンテンツが変更された場合、必ずしもコンテンツ配信サービスプロバイダに通知しない。さらに、キャッシュ34は、プロキシキャッシュ、縁部キャッシュ(edge cache)、フロントエンドキャッシュ、逆キャッシュ(reverse cache)等であってもよいことを理解すべきである。
【0004】
図2の場合、コンテンツがWebサイトからキャッシュ34に配信されると、メタ記述またはメタデータと呼ばれるヘッダが、コンテンツと一緒に配信される。メタデータはコンテンツのサブセットであってもよいし、またはコンテンツのある種の特性を表示することもできる。例えば、メタデータは、最後に修正した日付、ある時期にコンテンツが期限切れになる推定値、コンテンツが直ちに期限切れになるか、またはキャッシュすべきでないという表示を含むことができる。コンテンツおよびメタデータが配信された後で、メタデータが、キャッシュ34内にコンテンツを記憶するように表示している場合には、コンテンツが、キャッシュ34に記憶される。
【0005】
ユーザー36(ユーザー1)が、Webサイト28(Webサイト1)からあるページ(例えば、index.html)へのアクセスを要求した場合には、ユーザー1のWebブラウザは、最初に、Webサイト1のドメイン名に対応するインターネットプロトコル(IP)アドレスを見出すために、要求をドメイン名サーバー(DNS)に送る。図2の例の場合のように、キャッシュシステム26を利用した場合には、WebブラウザをWebサイト1にではなく、プロキシサーバー32に送ることができる。その後で、プロキシサーバー32は、要求したコンテンツがキャッシュ34内に存在するかどうかを判断する。
【0006】
しかし、要求したコンテンツがキャッシュ34内で見出せたとしても、キャッシュ34内のコンテンツが最新のものであるかどうかを判断しなければならない。この問題は、データベース同期として説明することができる。すなわち、キャッシュ34およびWebサイト1としては、同じコンテンツを持つことが望ましい。しかし、すでに説明したように、加入者Webサイトは、そのコンテンツが変更されたとき、それをプロキシサーバー32に知らせることができない。それ故、プロキシサーバー32は、コンテンツが最新のものであることを容易に判断できるように、キャッシュ34内に記憶している、要求されたコンテンツに関連するメタデータをチェックする。
【0007】
キャッシュ34内で要求されたコンテンツが見出され、メタデータが期限切れの推定日時が、まだ来ていないことを示している場合には、ある種のキャッシュシステムは、単に、コンテンツをユーザー1に直接配信する。しかし、もっと高度なキャッシュシステムの場合には、必要なコンテンツが、最後に更新された日時に関する情報を求めて、Webサイト1に要求を送ることができる。キャッシュ34への最後のリフレッシュ以降にコンテンツが更新されている場合には、キャッシュ34内に現在入っているコンテンツは最新のものではなくなり、最新のコンテンツが、ユーザー1に配信される前に、Webサイト1からキャッシュ34に配信される。しかし、コンテンツが変更されたかどうかを判断するためにWebサイトをチェックするこのプロセスは、より広い帯域幅またはシステムリソース利用を必要とすることも理解すべきである。
【0008】
同様に、キャッシュ34内で要求されたコンテンツを見出したが、そのコンテンツが直ちに時間切れになるものである場合には、ある種のキャッシュシステムは、単に、Webサイト1からコンテンツを取り出し、それをユーザー1に配信する。しかし、ユーザーが、データが最新のものであるかどうかの確認を要求した場合には、ある種のキャッシュシステムは、必要なコンテンツが最後に更新された日時に関する情報を求めて、Webサイト1に要求を送ることができる。キャッシュ34に対する最後のフレッシュの前にコンテンツが更新された場合には、コンテンツは依然として最新のものであり、キャッシュシステムは、そのコンテンツが「直ちに期限切れになる」状態であっても、それをユーザー1に配信する。
【0009】
要求されたコンテンツがキャッシュ34内に入っていない場合には、プロキシサーバー32は、必要なWebページ(例えば、index.html)のテキストを取り出すために、Webサイト1に要求を送る。ユーザー1のWebブラウザが、index.htmlを受信した後で、ブラウザはhtmlページを分析し、画像またはアイコンのような、任意の埋設されているオブジェクトを取り出すために、Webサイト1に追加要求を発行することができる。しかし、キャッシュシステム26を利用している場合には、プロキシサーバー32は、最初に、埋設されているオブジェクトがキャッシュ34内で有効であるかどうかを判断する。すべてのトラフィック(すなわち、データの流れ)は、プロキシサーバー32内のログファイル38内に記録される。ログファイル38は、要求の発行が行われる位置のIPアドレス、取り出したオブジェクトのURL、各性質のタイムスタンプ等を含むことができる。プロキシサーバー32は、通常、多くのエンドユーザーにより共有され、そのため、同じ様な利害関係を持つユーザーが、キャッシュ34内のコンテンツにアクセスできることを特筆しておく。すなわち、ユーザー1があるページにアクセスし、そのページがキャッシュ34に記憶されている場合であって、他のユーザー40(ユーザー2)が同じページを要求した場合には、プロキシサーバー32は、単に、キャッシュ34内のコンテンツをユーザー2に供給することができる。
【0010】
ある種のキャッシュシステムの場合には、コンテンツに対するエンドユーザーの要求がない場合でも、リフレッシュを実行することができる。ユーザーからの要求を受信しない場合でも、キャッシュは、要求を、Webサイトのコンテンツが、最後に更新された日時を判断するために、キャッシュ内にコンテンツを配信するWebサイトに要求を送ることができる。コンテンツが変更された場合には、そのコンテンツは、Webサイトからキャッシュに、リフレッシュされて送り返される。それ故、エンドユーザーからコンテンツに対する要求を受信した場合には、キャッシュ内のコンテンツが最新のものであり、直ちにエンドユーザーに直接送信される可能性が高い。
【0011】
ネットワーク帯域幅リソースおよびシステムリソースは、インターネットに接続しているエンドユーザーおよびプロキシサーバーにとって重要なものである。エンドユーザーおよびプロキシサーバーは、帯域幅および接続リソースを入手するために、相互に「競合している」と見なすことができる。しかし、エンドユーザーおよびプロキシサーバーの目標は同じである。すなわち、最も速い応答時間をユーザーに供給することである。
【0012】
図3は、通常のプロキシサーバー42が利用することができる接続を示す。個々の要求に対する最も速い応答時間は、要求されたコンテンツが、プロキシサーバーキャッシュ内に位置していて、最新のものである場合に達成することができる。そのため、プロキシサーバー42は、インターネットを通してWebサイトからコンテンツを取り出す必要はない。この状況は、キャッシュ「ヒット」と呼ばれる。キャッシュヒット率が非常に高い場合には、システム全体を通して、最も速い応答時間が達成される。それ故、予め取り出しておき44、リフレッシュしておき、確認しておけば、最新のコンテンツが増え、キャッシュヒット率がもっと高くなり、一人のエンドユーザーに対する応答時間がもっと速くなることをハッキリと理解することができるだろう。しかし、折り合いをつける必要がある。非常に高いキャッシュヒット率を達成するためには、プロキシサーバー42は、コンテンツのリフレッシュ、予備取り出し、取出し、または予備確認44をキャッシュに対して行うために、ネットワークの大きなパーセンテージの帯域幅を使用しなければならない。しかし、大量のフレッシュにもかかわらず、エンドユーザーが、キャッシュ内にまだリフレッシュしていない、または単にキャッシュに位置していないコンテンツを要求する事態が起こる場合がある。そのような場合には、プロキシサーバー42は、Webサイトからそのコンテンツを要求するために、要求取出し46を発行しなければならない。しかし、他のコンテンツをリフレッシュするために、帯域幅の過度の帯域が現在利用されている場合には、Webサイトからの要求コンテンツを取り出すために、キャッシュにとって有効な帯域幅が不十分である場合があり、コンテンツ取り出しの応答時間が、実際にはかなり長くなる場合がある。それ故、キャッシュリフレッシュおよび予備取り出しは、Webサイトのコンテンツ取出しと競合し、Webサイトのコンテンツ取出しに悪影響を及ぼす恐れがあることを理解すべきである。
【0013】
もちろん、任意の瞬間に、利用していない帯域幅がある場合には、要求しているエンドユーザーが利用することができるように、最も優先権の高いコンテンツをキャッシュ内に予め取り出しておくことは合理的な方法である。例えば、Webサイトからコンテンツを取り出すために、帯域幅の20%を利用していると仮定した場合、エンドユーザーがコンテンツを要求した場合には、キャッシュヒットは起こらない。上記取出しのために、帯域幅の20%が利用されている場合には、帯域幅の80%は利用されていない。この利用されていない帯域幅は、キャッシュ内に他のコンテンツを予め取り出すために利用することができる。そのため、エンドユーザーが、そのコンテンツを要求した場合には、該コンテンツは、エンドユーザーにとって有効となる。
【0014】
ネットワーク帯域幅に対するキャッシュサーバーリフレッシュ、予備取り出し、Webサイトコンテンツ取り出しの間で競合が行われ、またこれらのプロセスに帯域幅が割り当てられる結果、ユーザーの応答時間が影響を受けるので、最善の応答時間を達成するために、キャッシュサーバーリフレッシュおよび予備取り出しのための帯域幅の最適な割当てを決定するための方法が必要になる。さらに、帯域幅制限のために、キャッシュ内に記憶しているコンテンツのほんの一部しかリフレッシュまたは予備取り出しできない場合には、キャッシュヒット率を最大にし、応答時間を最短にするために、どのコンテンツをリフレッシュし、予め取り出すべきかを決定する方法が必要になる。
【0015】
【発明が解決しようとする課題】
それ故、本発明の実施形態の一つの利点は、最短のエンドユーザー応答時間を達成するために、キャッシュサーバーリフレッシュおよび予備取り出しのための帯域幅の最適な割当てを決定する効率的なWebコンテンツ取り出しおよびリフレッシュ用のインテリジェントネットワーク帯域幅およびシステムリソースを利用するための方法および装置を提供することである。
【0016】
本発明の実施形態のもう一つの利点は、有効なネットワーク帯域幅の変動を考慮に入れながら、最短のエンドユーザー応答時間を達成するために、キャッシュサーバーリフレッシュおよび予備取り出しのための帯域幅の最適な割当てを決定する効率的なWebコンテンツ取り出しおよびリフレッシュを行う目的で、インテリジェントネットワーク帯域幅、およびシステムリソースを利用するための方法および装置を提供することである。
【0017】
本発明の実施形態のさらにもう一つの利点は、最短のエンドユーザー応答時間を達成するために、キャッシュサーバーリフレッシュおよび予備取り出しのためのネットワーク接続の最適な数を決定する効率的なWebコンテンツ取り出しおよびリフレッシュを行う目的で、インテリジェントネットワーク帯域幅およびシステムリソースを利用するための方法および装置を提供することである。
【0018】
本発明の実施形態のさらにもう一つの利点は、ネットワーク接続の有効数の変動を考慮に入れながら、最短のエンドユーザー応答時間を達成するために、キャッシュサーバーリフレッシュおよび予備取り出しを行う目的で、ネットワーク接続の最適な数を決定する効率的なWebコンテンツ取り出しおよびリフレッシュを行うために、インテリジェントネットワーク帯域幅およびシステムリソースを利用するための方法および装置を提供することである。
【0019】
本発明の実施形態のさらにもう一つの利点は、キャッシュヒット率および応答時間を最適なものにするために、どのコンテンツをリフレッシュし、予備取り出しを行うべきかを決定する効率的なWebコンテンツ取り出しおよびリフレッシュを行うために、インテリジェントネットワーク帯域幅およびシステムリソースを利用するための方法および装置を提供することである。
【0020】
【課題を解決するための手段】
上記および他の利点は、最適な予備取り出し帯域幅割当ての数値を利用して、少なくとも1つのプロキシサーバーが、少なくとも1つのコンテンツプロバイダオリジナルサイトからコンテンツを取り出すことができるようにするためのコンテンツ配信サービスプロバイダにより達成することができる。コンテンツ配信サービスプロバイダは、コンテンツを要求するための複数のエンドユーザーブラウザ、上記コンテンツを配信するための少なくとも1つのコンテンツプロバイダオリジナルサイト、および上記コンテンツを記憶するための少なくとも1つのプロキシサーバーを含むコンテンツを記憶し、配信するためのシステムの一部である。これらの素子は、通信用のネットワークにより相互に接続している。
【0021】
コンテンツ配信サービスプロバイダは、下記の目的のためにプログラムされている。
・ d(b)は、bの帯域幅単位が、コンテンツの予備取り出しに利用された場合に観察された単位遅延であり、congestion(Util)は、congestion(Util)=β/(Utilθ+α)+φ、または、congestion(Util)=β×(1.0−Util)α+φで表すことができる場合に、bの帯域幅単位を利用して、サイズ、size(o)のコンテンツoの検索時間を、ret(o)=congestion×size(o)×d(b)、としてモデル化すること。
・ Pは、予備取り出し帯域幅であり、Bは、システムにとって有効な全帯域幅であり、r(t)=(1−σ(P))×u(t)は、少なくとも1つのプロキシサーバー内に記憶されていないコンテンツに対するエンドユーザーブラウザ要求を検索するために、システムが利用する帯域幅の広さであり、σ(P)は、帯域幅がPである場合のキャッシュの新しさ(freshness)および有効性(availability)の数値であり、u(t)は、ユーザーのアクセス速度である場合に、時刻t0において、少なくとも1つのコンテンツプロバイダオリジナルサイトから取り出したコンテンツについて、少なくとも1つのプロキシサーバーが観察した遅延の量を、ret(p)=congestion((P+r(t0))/B)×r(t0)×d、としてモデル化すること。
・ δret(P)/δP=0を解くことにより、最適の予備取り出し帯域幅割当ての数値を計算すること。
・ 少なくとも1つのプロキシサーバーへ、最適の予備取り出し帯域幅割当て値Pを通信すること。
【0022】
当業者であれば、添付の図面を参照しながら、本発明の実施形態の下記の詳細な説明を読めば、本発明の実施形態の上記および他の目的、機能および利点を理解することができるだろう。
【0023】
【発明の実施の形態】
好ましい実施形態の以下の説明においては、本明細書の一部を形成し、本発明を実施することができる例示としての特定の実施形態を示す添付の図面を参照する。他の実施形態を利用することもできるし、本発明の好ましい実施形態の範囲から逸脱することなしに構造を変更することができることを理解すべきである。
【0024】
コンテンツに対する個々のエンドユーザーの要求を処理するための最も速い応答時間は、要求コンテンツが、プロキシサーバーのキャッシュ内に位置していて、最新(古くなっていない)場合に達成することができる。この状態をキャッシュ「ヒット」と呼ぶ。キャッシュヒットがある場合には、キャッシュから要求を行っているエンドユーザーのブラウザへ直接配信することができ、プロキシサーバーは、インターネットを通してコンテンツプロバイダのWebサイトからコンテンツを取り出す必要はない。キャッシュヒット率が非常に高い場合には、システム全体を通して、最も速い応答時間が達成される。それ故、キャッシュ内に記憶しているリフレッシュ、予備取り出し、および予備確認の数を増やせば、最新のコンテンツが増え、キャッシュヒットの数が増大し、一人のエンドユーザーに対する応答時間がもっと短くなることを理解することができるだろう。しかし、折り合いをつける必要がある。非常に高いキャッシュヒット率を達成するためには、プロキシサーバーは、コンテンツをリフレッシュし、キャッシュ内に予備取り出しするために、ネットワークの大きなパーセンテージの帯域幅を利用しなければならない。しかし、大量のリフレッシュを行っても、エンドユーザーが、キャッシュ内にまだリフレッシュしていないコンテンツを要求する事態が起こる場合がある。そのような場合には、キャッシュは、Webサイトからそのコンテンツを要求しなければならない。しかし、他のコンテンツをリフレッシュするために帯域幅の過度の帯域が現在利用されている場合には、Webサイトからの要求コンテンツを取り出すために、キャッシュにとって有効な帯域幅が不十分である場合があり、コンテンツ取り出しの応答時間が、現実にかなり長くなる場合がある。それ故、キャッシュリフレッシュおよび予備取り出しは、Webサイトのコンテンツ取り出しと競合し、Webサイトのコンテンツ取り出しに悪影響を及ぼす恐れがあることを理解すべきである。
【0025】
結合した帯域幅利用が少ない場合には、すなわち、結合ユーザー帯域幅利用および予備取り出し帯域幅利用が、有効な最大バックボーン帯域幅よりかなり下方にある場合には、ユーザーの要求および関連する応答時間は影響を受けない。しかし、すでに説明したように、結合帯域幅利用が最大有効帯域幅に近づくと、ネットワークを通してサービスを受けるユーザー要求を処理する際に、有意な待ち時間が発生する場合がある。
【0026】
本明細書で使用する応答時間とは、単に、ユーザーの要求と、ユーザーへのコンテンツの配信との間の実際の時間ではないことを理解すべきである。この実際の時間は、予測することができないし、エンドユーザーの物理的位置、および必要なコンテンツにアクセスするために、ネットワーク内において通過しなければならないゲートウェイの数のような要因により異なる。それ故、この場合における、応答時間のより合理的な表現は、キャッシュヒット率である。キャッシュヒット率は、そのコンテンツに対して要求を行った場合に、エンドユーザーが、キャッシュからコンテンツに直接アクセスすることができる回数の百分率である。すなわち、エンドユーザーが、キャッシュから直接必要なコンテンツに、10回のうち8回アクセスできた場合には、キャッシュヒット率は80%になる。
【0027】
また、「リフレッシュ」「取り出し」、「予備取り出し」、「確認」および「予備確認」という用語は、これらの用語が、同じ方法で、帯域幅またはシステムリソースを必要とするという点で類似していることを特筆しておく。それ故、本明細書の説明においては、「リフレッシュ」、「取り出し」、「予備取り出し」、「確認」または「予備確認」しか参照しないが、本明細書に記載する技術は、「リフレッシュ」、「取り出し」、「予備取り出し」、「確認」および「予備確認」に適用される。
【0028】
図4は、本発明のある実施形態のコンテンツを記憶し、配信するためのシステム48である。図4の場合には、キャッシュシステム50は、コンテンツ配信サービスプロバイダ52の制御の下で動作する。上記プロバイダ52は、最短の応答時間を達成するためのキャッシュサーバーリフレッシュおよび予備取り出し用の最適帯域幅割当てを決定することができ、最短の応答時間を達成するためのキャッシュサーバーリフレッシュおよび予備取り出しのためのネットワーク接続の最適な数を決定することができ、または、キャッシュヒット率および応答時間を最適にするために、キャッシュ内に記憶しているコンテンツの中のどれをリフレッシュ、または予備取り出しすべきかを決定することができる。コンテンツ配信サービスプロバイダ52の一例としては、「効率的にコンテンツを配信するためのシステムおよび方法」という名称の2000年4月7日付の、米国係属特許出願第09/545,805号が開示している、「CachePortal(キャッシュポータル)」(商標)がある。上記米国特許出願は、引用によって本明細書の記載に援用する。図4のコンテンツ配信サービスプロバイダ52は、多数のキャッシュシステムを任意に制御する独立のサーバーであってもよいし、または、コンテンツサービスプロバイダ52は、本明細書に記載するように、各キャッシュシステム50内のプロキシサーバー54の一部であってもよい。
【0029】
<最適な予備取り出し帯域幅の決定>
キャッシュ内にコンテンツを予備取り出しするために予約しておかなければならないネットワーク帯域幅の最適な幅を決定するための方法について説明する。Bを、システムにとって有効な全帯域幅とし、p(t)を、キャッシュ内にコンテンツを予備取り出しするために使用する帯域幅の幅とする。予備取り出しを行う必要があるコンテンツは、ユーザーのアクセス頻度およびキャッシュの新しさにより異なり、キャッシュの新しさは、キャッシュを更新するために使用する帯域幅の幅により異なる。予備取り出しする帯域幅p(t)および他のパラメータが分かれば、キャッシュの新しさおよびσ(p(t))の有効性を維持できると仮定する。その場合、ユーザーアクセス速度u(t)が分かれば、実効帯域幅のσ(p(t))×u(t)をキャッシュ(すなわち、最新のデータに対するキャッシュヒット)から入手することができる。従って、コンテンツのr(t)=(1−σ(p(t)))×u(t)を、ネットワークを通してWebサイトから取り出さなければならない。(すなわち、データはキャッシュ内に位置していないか、または取り出されていない)。
【0030】
ユーザーのアクセス速度は、時間と共に変動する。それ故、時刻t0までのr(t)の性質を示す関数hr(t)(すなわち、t<t0に対するhr(t)=r(t)が、決定でき、経験的に入手することができ、インターネットサービスプロバイダ(ISP)が供給することができると仮定する。時刻t0においては、予め取り出す帯域幅の幅pが必要となるので、p(t)=Pである場合には、ネットワークで観察される全検索時間は最も短くなる。
【0031】
bの帯域幅単位を利用するサイズ、size(o)のコンテンツOの検索時間は、ret(o)=congestion×size(o)×d(b)、としてモデル化することができる。この場合、d(b)は、bの帯域幅単位が、コンテンツの検索に利用された場合に観察された単位遅延である。パラメータ、congestionは、オブジェクトの大きさには左右されないが、ネットワーク帯域幅の利用により異なることを特筆しておく。
【0032】
図5は、帯域幅利用と混雑(congestion)の間の関係である。図5の遅延54は、ユーザーの要求に対する応答時間と等しいことを理解すべきである。図5に示すように、0%から80%までの帯域幅利用は(参照番号56参照)、遅延内に僅かな変化しかを起こさない。しかし、帯域幅利用が80%、そしてその後で90%を超すと、ユーザーの要求に対する応答時間は劇的に増大する。帯域幅利用の回数がさらに多くなると、コンテンツに対する異なる要求の衝突が起こる。衝突が起こると、CPUはその要求を再度送信し始めることができる。衝突の回数がもっと多くなると、要求の再送信の回数がさらに増え、まもなく、すべての要求が相互に衝突し、性能の低下がおこり、完全に停止する場合もある。図5は、任意のタイプの帯域幅利用をカバーすることを理解すべきである。
【0033】
この性質は、congestion(Util)=β/(Utilθ+α)+φおよびcongestion(Util)=β×(1.0−Util)α+φを含む種々の関数で近似することができる。この場合、Utilは、最大ネットワーク帯域幅に対する、利用したネットワーク帯域幅の比率を表し、パラメータ、α、β、φおよびθは、混雑関数(congestion function)を混雑曲線(congestion curve)に適当に適合させるために利用され、統計的に、経験的に入手することができ、またはISPにより供給される。データ取出しリンクの性質を表示する混雑関数が分かっている場合には、時刻t0において取り出したデータ要求により観察した遅延の量は、下記式によりモデル化することができる。
ret(P)=congestion((P+r(t0))/B)×r(t0)×d
ここで、Bは全帯域幅であり、r(t)=(1−σ(P))×u(t)は、キャッシュ内に入っていないユーザー要求を検索するために、システムが利用している帯域幅の幅である。
【0034】
例えば、図6は、予備取り出しのために利用する帯域幅とエンドユーザーの応答時間との間の関係を、関数P0/(B−R)で示す。このグラフのために使用した混雑関数は、congestion(Util)=1.0/(1.0−Util6)である。この関数は、第一の近似に対応することを特筆しておく。この場合、α=−1.0、β=−1.0、θ=6、φ=0.0である。すでに説明したように、帯域幅利用は、実際には、二つの成分に分解される。第一の成分はユーザーの要求を処理し、第二の成分は予備取り出しを処理する。図6が示すように、予備取り出し用に利用する帯域幅の幅は、0%から60%に増大し(参照番号58参照)、エンドユーザーの応答時間は短くなる。しかし、すでに説明したように、予備取り出しのためにあまりに広い帯域幅を使用すると、応答時間が長くなる。図6は、予備取り出しに60%以上の帯域幅を利用した場合、全体の応答時間が、80%のところで増大を始め、応答時間が劇的に増大する様子を示す。図6は、帯域幅利用が、(コンテンツ予備取り出しのために、余分な全帯域幅を割り当てることにより)100%に近づいた場合、応答時間が悪影響を受ける様子を示す。
【0035】
帯域幅利用が100%に近づくにつれて、ネットワークを通してコンテンツを配信しようとする要求が渋滞するので、衝突の回数がますます多くなる。すでに処理中の要求を処理するのに帯域幅が不十分であるので、新しい要求は引続き衝突および渋滞を続ける。その結果、トラフィックは完全に渋滞してしまって、その状態を解消することができない。不完全な要求が処理されず、他の不完全なユーザーの要求と引続き衝突を続けるので、実際の通信は停止し、その結果、トラフィックは停止してしまう。このようなトラフィックの完全な渋滞を防止する一つの方法は、要求の受付を制限することである。要求受付の制限は、帯域幅利用が100%に近づくのを許さない防衛手段の一つの形式である。例えば、帯域幅利用が、80%のマークまで増大するのを許すが、80%になると、ユーザーの要求は受け付けないという手段である。いつでも有効な状態に維持されている残りの20%は、すでに進行中の要求を処理するために利用される。現在の要求の処理が完了するまで、他のリフレッシュまたは予備取り出しは計画されない。もちろん、防衛手段として余りに多くの帯域幅が留保した場合には、ユーザーの応答時間は最も短くはならない。
【0036】
図6の利用曲線は、ユーザーの応答時間が最も短い場合、最適な予備取り出し帯域幅割当てが、勾配が0である曲線の最も低い点で見出せることを示す。この最適な予備取り出し帯域幅割当ての数値は、Pに対する下記の微分方程式を解くことにより計算することができる。
δret(P)/δP=0
【0037】
<変動する帯域幅利用の考察>
上記方法は、r(t)が、ある時間の間の定数(R=r(t0))であると仮定することにより上記微分方程式を解く。しかし、すでに説明したように、キャッシュ内に位置していないコンテンツを検索するために使用する帯域幅の幅は一定ではなく、時間の関数(r(t))である。さらに、「帯域幅の消費量は、オブジェクトを取り出すのに十分な時間の間一定である」という仮定が成立しない場合には、r(t)の数値の僅かな増大が検索時間を非常に長くする場合がある。
【0038】
例えば、すでに説明したように、図6は、帯域幅の20%の一定部分が、ユーザー要求用に利用されると仮定した場合の、予備取り出し用に使用する帯域幅利用曲線を示す。しかし、ユーザーの要求のために利用する帯域幅の百分率が、20%から変動した場合には、予備取り出し用の60%の帯域幅も変動する。すなわち、コンテンツを取り出すためのエンドユーザーの帯域幅利用パターンが、20%の点の付近で変動した場合には、予備取り出し用の帯域幅利用も、60%の点の付近で変動する。しかし、図6は、予備取り出し用の60%に対する最適な帯域幅利用が予備取り出し用の80%に対する帯域幅の不十分な百分率に非常に近くなり、そのため、これらの変動が、応答時間のかなりの延長を起こす恐れがある場合を示す。
【0039】
この変動を、エンドユーザーが利用する帯域幅の幅の中に収容する一つの方法は、図6の例に示す計算した最適な点を使用しないで、それより低い点を使用する方法である。図6は、予備取り出し用の帯域幅利用が、60%から50%に低下した場合に、応答時間にわずかな違いが起こるが、その変化は、エンドユーザー要求が使用する帯域幅内の変動を収容するための安全限界の余分な手段を提供する。
【0040】
予備取り出しのための最適な帯域幅利用は、多数の他の要因によって異なることを理解すべきである。例えば、コンテンツを予備取り出しするために使用するアルゴリズムは不正確な場合があり、その結果、多数のユーザーの要求が、Webサイトからコンテンツにアクセスしなければならなくなる。キャッシュ内に記憶されているコンテンツは、また、頻繁に変化する場合があり、その結果、ユーザーの要求は、頻繁に古くなったコンテンツに遭遇することになり、Webサイトからコンテンツにアクセスしなければならなくなる。これらの要因は、Webサイトからコンテンツを取り出すのに使用する、帯域幅の百分率に影響を与え、そのため、エンドユーザーの要求の全応答時間に影響を与える。
【0041】
<予備取り出し帯域幅の調整>
帯域幅消費量の小さな変動が、検索時間の長い延長を引き起こす確率を小さくするために、帯域幅消費量の関数のもう一つの性質を考察することができる。この性質は、(それを有効である場合には)リソース予約契約を利用することにより、または検索帯域幅およびまた予備取り出し帯域幅の最大幅を推定するための履歴(history)hr(t)を利用することによって見出すことができる。
【0042】
予備取り出し帯域幅は、下記のように、もう一つの性質を使用して調整することができる。
・ Pに対する現在の帯域幅消費量(R=r(t0))を使用して、δret(P)/δP=0を解くこと。
・ 現在の帯域幅消費量(R=r(t0))を使用して、ret(P)を見出すこと。
・ 履歴hr(t)を使用して、期間[t0,t0+ret(P)×p]内の最大の帯域幅消費量Rmaxを推定すること。この場合、pは今後の参照の度合である。・ Padjustedに対する帯域幅の最大要件(R=Rmax)を使用して、δret(P)/δP=0を解くこと。
【0043】
Padjustedを、帯域幅消費量の最悪の場合の性質の推定値を使用して計算すること。Padjustedは、今後のことを全然考慮しないで計算したPより小さい可能性が高い。
【0044】
<使用の改善>
前節においては、帯域幅利用の最悪の場合の性質の推定により予備取り出し帯域幅を選択することにより、エンドユーザー変動を考慮に入れる最悪の場合の方法について説明した。この方法は、ピークのユーザーアクセストラフィックを選択し、期間中、上記ピークは一定であると仮定する。その後で、このピーク値は、最適な帯域幅予備取り出し使用を発生するために使用され、特定の式の形で表される。しかし、この方法は、有効な帯域幅利用を不必要なほど低減する場合がある。この節においては、最悪の場合の帯域幅を使用しないで帯域幅利用を予測しようとする、改善された方法について説明する。
【0045】
この節で説明する基本的なコンセプトは、エンドユーザーのアクセスパターンをチェックし、その後で、予測した今後のエンドユーザーの帯域幅利用に基づいて、予備取り出しのために使用する帯域幅を再計算することである。それ故、例えば、一定期間の間に、エンドユーザーの帯域幅利用がある量だけ変化した場合には、次の一定期間中にそれを予測することができ、エンドユーザーの帯域幅利用は、その割合で増大を続ける場合がある。予測したエンドユーザーの帯域幅利用に基づいて、予備取り出しのために使用する帯域幅の新しい数値を計算することができる。もちろん、エンドユーザーの帯域幅利用の変化が最小である場合には、エンドユーザーの帯域幅利用の新しい予測数値を予備取り出しのために使用するために、帯域幅を再計算する必要は全然ない。それ故、予備取り出しのために使用する帯域幅の最適な百分率は、最適な応答時間を維持するために引続き再計算される。
【0046】
予備取り出しのための最適な帯域幅使用のこの計算がスタートすると、ユーザーの要求に対してどれだけの帯域幅が使用されるのか、また、予備取り出しのためにどれだけの帯域幅が使用されるのかについての最初の仮定が行われる。一例を挙げると、帯域幅の20%がユーザーの要求のために使用され、60%が予備取り出しのために使用され、これらの百分率により、二つの第二のユーザーの要求の応答時間が決定されると仮定する。一定期間(例えば、5分間)が経過した後で、ユーザーの要求のためにどれくらいの帯域幅が使用されるのか、また、予備取り出しのためにどれくらいの帯域幅が使用されるのかを決定するために、新しい計算が行われる。さらに、応答時間がもう一度測定される。上記百分率が、前の測定値より劇的に変化している場合には、その5分間の間にある傾向が発生したと仮定することができる。この傾向は、5分間より前に再計算を行った場合には恐らく検出することができたであろうから、再計算の時間をもっと早い時間(例えば、3分)に移動する。より早い時間に、帯域幅利用および応答時間を再計算することにより上記傾向を早期に検出することができ、帯域幅利用の調整も早期に行うことができる。
【0047】
例えば、5分間の間に、エンドユーザーが利用した帯域幅が20%ではなく、25%であり、予備取り出しのために使用した帯域幅が60%ではなく、55%であったと決定されたと仮定する。これらの違いは、最初の帯域幅利用が最適なものではなく、調整が必要であったことを示す。
【0048】
一方、5分後に、エンドユーザーが使用した帯域幅が20%のままであり、予備取り出しのために使用した帯域幅が60%のままであった場合には、帯域幅利用が、最適使用に近く、変更が必要ないことを示す。それ故、前の帯域幅の数字と5分後の帯域幅の数字の間に小さな違いが認められる場合には、再計算の点を(例えば、10分後というように)後にずらすことができる。すなわち、帯域幅利用の数字が一定であり、最適値に近い限りは、帯域幅利用の数字および応答時間の再計算はあまり頻繁に起こらない。しかし、帯域幅利用の数字が、測定の度に変化する場合には、計算の間の時間を徐々に短くする。
【0049】
予備取り出しのために使用する帯域幅の百分率は、本明細書で説明するように、予備取り出し、リフレッシュ、または、単に、キャッシュ内のコンテンツの現状を確認するために使用する帯域幅の百分率を意味することを理解すべきである。
【0050】
さらに、エンドユーザーの帯域幅利用に対する今後の数値の予測は、必ずしも、簡単な線形予測ではないことも理解すべきである。それどころか、変動するエンドユーザーの帯域幅アクセスパターンを記述するために、複雑な関数を開発することができる。この方法の場合、変動するエンドユーザーの帯域幅のパターンも予測することができる。しかし、この改良した方法は、キャッシュシステムを増大する遅延応答時間の領域に入れる予備取り出し帯域幅利用となる、予測したエンドユーザーの帯域幅利用の数値を計算しない。その代わりに、上記計算は、良好なエンドユーザーの応答時間を保存する予備取り出し帯域幅利用数を計算する。
【0051】
Pと、Padjustedとの間の違いが非常に大きい場合には、(推定した)最悪の場合の消費量の代わりに、(推定した)平均の帯域幅消費量を考慮に入れるために、下記のように再調整することができる。
・ Δtを推定最大使用帯域幅(Rmax)により計算したret(Padjusted)×pとする。
・ 平均使用を、
【数45】
と定義する。
・ UtilavgおよびPavgを利用して、予想検索時間Retexp(Pavg)を定義する。
・ Pavgについて、δretexp(Pavg)/δPavg=0を解く。
【0052】
Pavgは、Pより小さく、Padjustedより大きい可能性が高い。さらに、Pavgは、帯域幅消費量の今後の性質を考慮して計算されるので、帯域幅消費量の変化により影響を受ける可能性は少ない。さらに、最悪の場合の性質に基づいて計算していないので、帯域幅利用は最悪の場合より良好である可能性が高い。
【0053】
この方法は、
【数46】
の数値を推定するための方法を必要とすることを特筆しておく。それ故、(リソース予約プロトコルを利用するシステムで有効な)帯域幅消費量についての予備知識が必要であり、または、システムの今後の性質を、その過去の性質についての有効な統計(hr(t))を利用して推定しなければならない。この情報は、ISPにより近似または供給することができる。
【0054】
<オブジェクトのリフレッシュおよび予備取り出しのスケジューリング>
予備取り出しのために利用すべき帯域幅の百分率が、ユーザーの実際のアクセスパターンに基づいて決定されると、次の段階において、エンドユーザーの問い合わせの頻度および更新の頻度に基づいて、予備取り出しの際に、どのコンテンツにより高い優先順位を与えるべきかが決定される。すなわち、所与の有効なネットワーク帯域幅、および記憶しているコンテンツに対する所与の問い合わせ頻度および所与の更新頻度に対して、この節は、オブジェクトのリフレッシュスケジュールおよび予備取り出しスケジュールを決定する。すなわち、どのコンテンツをリフレッシュすべきか、予備取り出しすべきかが決定される。
【0055】
予備取り出しの優先順位が最も高いコンテンツは、頻繁に問い合わせがあり、頻繁に更新されるコンテンツである。次の二つの最善の選択は、頻繁に問い合わせがあるが、頻繁には更新されないコンテンツ、または非常に頻繁に問い合わせはないが、非常に頻繁に更新が行われるコンテンツである。予備取り出しされる可能性が最も低いコンテンツは、頻繁に問い合わせが行われず、頻繁に更新されないコンテンツである。
【0056】
あるオブジェクトOiの取り出し、またはリフレッシュの優先順位は、
【数47】
として定義することができる。この場合、c1、c2およびc3は、問い合わせ頻度、更新頻度および期限切れ時間の要因に適用される配列係数(order coefficients)である。優先順位の順位が高ければ高いほど、そのオブジェクトは、リフレッシュまたは予備取り出しのために早期にスケジュールされる。
【0057】
優先順位の式から推測できるように、二つの情報の問い合わせ頻度および更新頻度が同じである場合には、期限切れ時間が関連要因になる。例えば、キャッシュ内に二つの情報が位置していると仮定する。すべての他のものが同じであり、一方が1分以内に期限切れになるように設定され、他方が5分経過後に期限切れになるように設定されていると仮定する。この例の場合、1分以内に記期限切れになるように設定されているコンテンツを最初に取り出すか、またはリフレッシュしなければならない。何故なら、他方のコンテンツは予備取り出し、またはリフレッシュを行う時間に余裕があるからである。
【0058】
しかし、上記優先順位の式には、配列係数c1、c2およびc3が存在することを特筆しておく。これらの配列係数は、ネットワークの状況により異なり、問い合わせ頻度、更新頻度および期限切れ時期の加重が異なる場合があることを示している。さらに、最適のリフレッシュおよび予備取り出しスケジュールに対するc1、c2およびc3の数値は、時間の経過と共に変化する場合がある。問題は、これらの配列係数の決定方法である。
【0059】
c1、c2およびc3に対する新しい数値を、前の期間からの統計を利用して割り当てることができる。この方法は、問い合わせ頻度および更新頻度に基づくスケジューリングであると見なすことができる。例えば、ある方法は、配列係数の最初の一組でスタートし、その一組の係数が、各コンテンツの優先順位番号を決定する。その後で、これらの優先順位の数値は、予備取り出しに対する順位を決定する。この優先順位のリストに基づいて、コンテンツの予備取り出しを、ある時間の間行うことができ、エンドユーザーの平均応答時間を決定することができる。例えば、係数の元の組を、5秒の間の予備取り出しの優先順位を決めるために使用した場合、エンドユーザーの平均応答時間が2秒になるような優先順位のリストを作成したと仮定する。この時間の間に、すべてのエンドユーザーの要求に対して、応答時間データが記録されると、収集したデータを、ある意味では、異なる係数を利用して、その時間を再生するために利用することができる。それ故、他の5秒の間の、予備取り出しの優先順位を決めるために、新しい組の係数を利用することができ、新しいエンドユーザーの平均応答時間が発生する。このプロセスは、全アクセス時間を最短にする一組の係数が選択することができるまで、複数の期間に対して反復することができる。
【0060】
別の例を説明すると、他の方法は、最初の組の配列係数を使用してスタートし、各コンテンツに対する優先順位番号、および予備取り出し優先順位を決定し、一連の各期間(例えば、T1、T2、T3等)の間の全応答時間を計算する。これらの期間の間、最適な応答時間を発生する一組の係数が見出されるまで配列係数を調整することができる。
【0061】
さらに他の実施形態の場合には、リフレッシュおよび予備取り出しスケジュールを、要求したコンテンツがキャッシュ内に位置していないか、リフレッシュされていない確率を最低限度まで低減することにより入手することができる。問題は下記の通りである。Oを一組のオブジェクトとする。予備取り出し帯域幅がP、期間がΔt、すべてのoi∈Oに対する、(単位時間の間の)問い合わせ確率がq(oi)、すべてのoi∈Oに対する(単位時間の間の)更新確率がu(oi)、すべてのoi∈Oに対する最後の検索時間がlr(oi)、すべてのoi∈Oに対するサイズがsize(oi)、および現在の時間がTである場合には、次のΔtの間にアクセスした古いオブジェクトの数が最も少なくなるように、次のΔt時間単位内に予備取り出しするために一組のオブジェクトOpを選択する。
【0062】
エンドユーザーのアクセスパターンは分かっているので、キャッシュ内に記憶しているコンテンツに対して、特定のコンテンツが、次にアクセスされる可能性を表す確率の数値を決定することができる。次のΔt時間単位の間にアクセスされる古いオブジェクトの予想の数字は、下記式により計算することができる。
【数48】
【0063】
上記確率は、問い合わせ頻度および更新頻度に基づくもであることを特筆しておく。oiがアクセスされる確率は、期限切れ時間で、問い合わせ頻度を除算したものに対応する。この方法と前の方法との間の違いは、上記式においては、過去を参照しないという点である。重要なことは、そのコンテンツが今後アクセスされる確率である。もちろん、そうするために、エンドユーザーのアクセスパターンを観察しなければならない。
【0064】
上記式の他の部分は、OIが古くなる確率である。更新頻度は統計的手段の中で、いつでも最も正確なものであるとは限らないことを特筆しておく。何故なら、特定の期間の間、特定のコンテンツ更新されたことが分かっていても、そのコンテンツが、その期間中に一回更新されたのか、または何回も更新されたのかが分からないからである。
【0065】
oiが、Δt時間単位内にアクセスされる確率は、prob(oiがアクセスされる)=1−(1−q(oi))Δ tである。次のΔt時間単位中に、あるオブジェクトが古くなる確率は、
【数49】
である。
【0066】
ユーザーが古いデータにアクセスする確率を最低限度まで低減するために、総和からそれを除去した場合、全体からみて減少が最も大きくなる一組のオブジェクトを選択しなければならない。すなわち、Opが、予備取り出しするためのオブジェクトの組である場合には、該オブジェクトが
【数50】
という有効な帯域幅内に収まる一方で、
【数51】
を最大にする必要がある。
【0067】
この問題は、「0−1ナップザック問題」として周知の問題である。この問題を解くために有効である多くのアルゴリズムがある。これらのアルゴリズムの説明は、アルゴリズム関係の文献に記載されているので、この問題は、当業者であればよく理解することができる。選択したオブジェクトが検索されると、これらのオブジェクトの最後の更新時間を適当に更新しなければならない。
【0068】
この問題の別の構成は、下記の通りであることを特筆しておく。古いオブジェクトの数をただ数える代わりに、各オブジェクトがアクセスされる予想回数を下記式により説明することができる。
【数52】
【0069】
Δt時間単位中に、オブジェクトoiに対する予想アクセス回数は、Δt×q(oi)である。それ故、代わりに下記の関数が最大になる。
【数53】
【0070】
<最適リソース利用率の決定>
今までの節においては、コンテンツの予備取り出しおよびリフレッシュを行うために、最適なネットワーク帯域幅を選択するための技術について説明した。この節においては、ネットワーク帯域幅が十分であるが、システム(すなわち、キャッシュサーバーまたはプロキシサーバー)リソースが、ボトルネックになっている状況における、ネットワーク接続の最適な関数を選択するために適応させることができる。
【0071】
Bを、プロキシサーバーが同時に開くことができる接続の数(すなわち、プロセスまたはスレッドの数)とする。Bは、ユーザー接続、コンテンツ接続および要求取出し接続の間で分割しなければならないことを特筆しておく。
【0072】
p(t)は、オブジェクトを、時刻tで、キャッシュ内に予備取り出しするために使用する接続の数を示すものとする。要求により取り出さなければならないオブジェクトの数は、ユーザーアクセス頻度およびキャッシュの新しさにより異なることを特筆しておく。オブジェクトの予備取り出しを行うために、p個の接続をすでに割り当て済みであると仮定する。また、これらp個の接続を使用して、キャッシュの新しさおよびσ(p)の有効性を維持できるものと仮定する。時刻tにおいて、u(t)接続のユーザーアクセス率(すなわち、各要求が、一つの接続を利用するu(t)要求)が分かっている場合には、σ(p)×u(t)接続を、プロキシキャッシュからサービスすることができる。残りのr(t)=(1−σ(p))×u(t)接続(すなわち、各要求が一つの接続を利用するr(t)=(1−σ(p))×u(t)要求)は、ソースから要求により取り出さなければならない。
【0073】
目標は、時刻t0において、p(t0)=Pである場合に、このプロキシサーバーのユーザーが観察した全検索時間(遅延)が最低限度に低減するような、接続Pの予備取り出し数を見出すことである。
【0074】
<検索時間および最適の予備取り出し帯域幅>
サイズがsize(o)のあるオブジェクトを、プロキシサーバーから、またプロキシサーバーへ検索する時間は、ret(o)=congestion×size(o)、としてモデル化することができる。この場合、パラメータ、congestionは、オブジェクトのサイズからは独立しているが、プロキシサーバーのところで開く同時接続の数に依存する。図7は、同時接続の数とcongestionとの間の関係を示す。この曲線は、図5の曲線とは異なる。しかし、近似した遅延関数60を、システムリソース利用と遅延との間の関係用の遅延関数62を表すために利用することができる。下記の二つの関数は、この目的のために利用することができる。
・ congestion(Util)=β/(Utilθ+α)+φ、および、
・ congestion(Util)=β×(1.0−Util)α+φ
ここで、Utilは、曲線された接続の最大数に対する、開いた接続の比率を示し、パラメータ、α、β、φおよびθは、統計的に得られた混雑曲線に混雑関数を適当に当てはめるために利用される。
【0075】
混雑関数が分かっている場合には、時刻t0において、プロキシサーバーのところで観察した遅延の長さを下記式でモデル化することができる。
ret(P)=congestion((P+r(t0)+u(t0))/B)×(u(t0)+r(t0))×平均的オブジェクトサイズ
ここで、Bは、許可された接続の最大数であり、u(t)はユーザー要求の数であり、r(t)=(1−σ(P))×u(t)は、キャッシュ内でリフレッシュされていないオブジェクトを要求により取り出すために必要な接続の数である。要求により取り出したコンテンツは、二回の遅延を経験することを特筆しておく。一方の遅延は、元のソースから取り出すための遅延であり、他方の遅延は、エンドユーザーに配信するための遅延である。
【0076】
図6によれば、接続の数が最大値に近づくと、検索時間が悪影響を受ける。図6は、また検索時間が最も短くなる予備取り出し接続の最適な数があることも示す。この最適値は、Pに対して、下記の微分方程式を解くことにより計算することができる。
δret(P)/δP=0
【0077】
<変動する接続の使用の考察>
上記方法の大きな欠点は、ある期間の間、r(t)が一定である(R=r(t0))であると仮定してのみ微分方程式を解くことができることである。しかし、キャッシュ内に位置していないオブジェクトを要求により取り出すのに必要な接続の数は一定ではなく、時間の関数である。さらに、r(t)の数値が少し増大すると、(図6にグラフで示す性質と同じように)検索時間が非常に長くなる場合がある。このような性質を防止するために、要求による取出し関数の今後の性質を考慮しなければならない。この性質は、許可された要求による取出しの関数を制限するか、またはその履歴hr(t)を利用することによって見出すことができる。
【0078】
<予備取り出し接続の調整>
今後の性質を使用する予備取り出し接続の数は、下記のように調整することができる。
・ 現在の帯域幅消費量(R=r(t0))を利用して、Pについてδret(P)/δP=0を解く。
・ RおよびPを利用して計算した混雑の数値を使用して、P個のオブジェクトを予備取り出しするために必要な時間の長さρを見出す。
・ 履歴hr(t)を利用して、期間[t0,t0+ρ]の間の最大要求による取り出し接続を推定する。この場合、ρはP個の接続を予備取り出しするのに必要な時間である。
・ Padjustedについて、最大推定値(R=Rmax)を使用して、δret(P)/δP=0を再度解く。
【0079】
Padjustedは、帯域幅消費量の最悪の場合の性質の推定により計算されるので、Padjustedは、将来のことを全然考慮しないで計算したPより小さい可能性が高い。
【0080】
<利用の改善>
上記方法は、ユーザーの要求の推定した最悪の場合および対応する要求による取出し要件により、予備取り出し接続の数を選択する。しかし、このことが、有効な帯域幅利用を不必要なほど低減する場合がある。
【0081】
Pと、Padjustedとの間の違いが非常に大きい場合には、この問題は、(推定の)最悪の場合の帯域幅消費量ではなく、(推定)平均の帯域幅消費量を考慮して、Pを再調整することにより除去することができる。
・ Δtを、Padjusted接続を予備取り出しするために必要な時間(最悪の場合)の長さとする。
・ 平均使用を下記式のように定義する。
【数54】
・ UtilavgおよびPavgを使用して、予想検索時間Retexp(Pavg)を定義する。
・ Pavgについて、δretexp(Pavg)/δPavg=0を解く。
【0082】
Pavgは、Pより小さく、Padjustedより大きい可能性が高い。さらに、Pavgは、今後の性質を考慮して計算されるので、帯域幅消費量の変化により影響を受ける可能性は低い。さらに、最悪の場合の性質に基づいて計算していないので、利用は、最悪の場合と比較すると良好である可能性が高い。
【0083】
この方法は、
【数55】
の数値を推定するためのある方法を必要とすることを特筆しておく。予備知識が必要である場合もあるし、または、その過去の性質についての有効な統計(hr(t))を使用して、システムの今後の性質を推定しなければならない場合もある。
【0084】
<コンテンツのリフレッシュおよび予備取り出しスケジューリング>
この節においては、上記技術により決定することができる所与の数の予備取り出し接続に対する、オブジェクトの問い合わせ頻度および更新頻度に基づいて、オブジェクトの予備取り出しスケジュールを決定するための技術を説明する。
【0085】
コンテンツOiの取り出しまたはリフレッシュの優先順位は、下記式のように定義することができる。
【数56】
ここで、c1、c2およびc3は、問い合わせ頻度、更新頻度および期限切れ時間の要因に適用される配列係数である。優先順位の数値が高ければ高いほど、そのコンテンツがリフレッシュまたは予備取り出しされる順位は早くなる。c1、c2およびc3は、ネットワークの状況により異なる場合があり、最適なリフレッシュおよび予備取り出しスケジュールに対するc1、c2およびc3の数値は、時間の経過と共に変化することを特筆しておく。c1、c2およびc3の新しい数値は、前の時期からの統計により割り当てることができる。
【0086】
Oを一組のオブジェクトとする。予備取り出し接続がP、期間がΔt、すべてのoi∈Oに対する(単位時間の間の)問い合わせ確率がq(oi)、すべてのoi∈Oに対する(単位時間の間の)更新確率がu(oi)、すべてのoi∈Oに対する最後の検索時間がlr(oi)、すべてのoi∈Oに対するサイズがsize(oi)、および現在の時間がtである場合には、次のΔtの間にアクセスする古いオブジェクトの数が最も少なくなるように、次のΔt時間単位内に予備取り出しするために、一組のオブジェクトOpを選択する。
【0087】
<スケジューリング技術>
次のΔt時間単位内にアクセスされる古いオブジェクトの予想数は、下記式により計算することができる。
【数57】
【0088】
oiが、Δt時間単位内に少なくとも一回アクセスされる確率は、prob(oiがアクセスされる)=1−(1−q(oi))Δ tである。次のΔt時間単位中に、あるオブジェクトが古くなる確率は、
【数58】
である。
【0089】
ユーザーが、古いデータにアクセスする確率を最低限度まで低減するために、総和からそれを除去した場合、全体からみて減少が最も大きくなる一組のオブジェクトを選択しなければならない。すなわち、Opが、予備取り出しするためのオブジェクトの組である場合には、該オブジェクトが、
【数59】
という有効な接続数内に収まる一方で、
【数60】
を最大にする必要がある。
【0090】
この問題は、「0−1ナップザックアルゴリズム」を利用して解くことができる。選択したオブジェクトが検索されると、これらのオブジェクトの最後の更新時間を適当に更新しなければならない。
【0091】
この問題の別の構成は下記の通りであることを特筆しておく。古いオブジェクトの数をただ数える代わりに、古い各オブジェクトがアクセスされる予想回数を下記式により説明することができる。
【数61】
【0092】
Δt時間単位中に、オブジェクトoiに対する予想アクセス回数は、Δt×q(oi)である。それ故、代わりに下記の関数が最大になる。
【数62】
【0093】
本発明の実施形態は、最も速いエンドユーザー応答時間を達成するために、キャッシュサーバーリフレッシュおよび予備取り出しのを行う目的で、帯域幅の最適な割当てを決定する効率的なWebコンテンツ取り出しおよびリフレッシュを行うため、インテリジェントネットワーク帯域幅、およびシステムリソースを使用するための方法および装置を提供する。さらに、本発明の実施形態は、有効なネットワーク帯域幅の変動を考慮に入れながら、最も速いエンドユーザー応答時間を達成するために、キャッシュサーバーリフレッシュおよび予備取り出しのための帯域幅の最適な割当てを決定する。
【0094】
本発明の実施形態は、最も速いエンドユーザー応答時間を達成するために、キャッシュサーバーリフレッシュおよび予備取り出しを行う目的で、ネットワーク接続の最適な数を決定する効率的なWebコンテンツ取り出しおよびリフレッシュを行うため、インテリジェントネットワーク帯域幅、およびシステムリソースを使用するための方法および装置を提供する。本発明の実施形態は、また、ネットワーク接続の有効数の変動を考慮に入れながら、最も速いエンドユーザー応答時間を達成するために、キャッシュサーバーリフレッシュおよび予備取り出しのためのネットワーク接続の最適な数も決定する。
【0095】
本発明の実施形態は、また、キャッシュヒット率および応答時間を最適にするために、どのコンテンツをリフレッシュし、予備取り出しすべきかを決定する効率的なWebコンテンツ取り出しおよびリフレッシュを行うために、インテリジェントネットワーク帯域幅およびシステムリソースを使用するための方法および装置も提供する。
【図面の簡単な説明】
【図1】エンドユーザーとWebサイトとの間の従来のコンテンツ配信経路の一例のブロック図である。
【図2】従来のキャッシュシステムの一例のブロック図である。
【図3】プロキシサーバーが利用することができる通常の接続の一例のブロック図である。
【図4】キャッシュサーバーリフレッシュおよび予備取り出しのための帯域幅の最適な割当てを決定するか、キャッシュサーバーリフレッシュおよび予備取り出し用のネットワーク接続の最適な数を決定するか、または本発明の実施形態に従ってユーザー応答時間を最短にするには、どのコンテンツをリフレッシュおよび予備取り出しすべきかを決定するためのコンテンツ配信サービスプロバイダを備える、例示としてのキャッシュシステムのブロック図である。
【図5】帯域幅利用と遅延との間の関係を示すグラフである。
【図6】予備取り出しのために利用した帯域幅の一部と、そこから、予備取り出しのために利用する帯域幅の最適な百分率が、本発明の実施形態により計算されるエンドユーザーの応答時間との間の関係を示すグラフである。
【図7】ネットワーク接続の数とエンドユーザーの応答時間との間の関係を示すグラフである。
【符号の説明】
48 コンテンツを記憶し、配信するためのシステム
50 キャッシュシステム
52 コンテンツ配信サービスプロバイダ
54 プロキシサーバー
Claims (24)
- コンテンツを記憶し、配信するためのシステムであって、コンテンツを要求するための複数のエンドユーザーブラウザと、コンテンツを配信するための少なくとも1つのコンテンツプロバイダオリジナルサイトと、通信用のネットワークにより相互に接続している、コンテンツを記憶するための少なくとも1つのプロキシサーバーとを含むシステムにおいて、
予備取り出し帯域幅割当て値を使用して、少なくとも1つのプロキシサーバーに、少なくとも1つのコンテンツプロバイダオリジナルサイトからコンテンツを予備取り出しさせるためのコンテンツ配信サービスプロバイダであって、該コンテンツ配信サービスプロバイダは、
d(b)は、bの帯域幅単位が前記コンテンツを予備取り出しするために利用された場合に観察された単位遅延であり、congestion(Util)は、congestion(Util)=β/(Utilθ+α)+φ、または、congestion(Util)=β× (1.0 - Util)α+φ、として表すことができる混雑関数であり、Utilは、最大ネットワーク帯域幅に対して利用されるネットワーク帯域幅の比率を表し、パラメータα、β、およびφが、前記混雑関数を帯域幅利用比率と応答遅延との関係を示す混雑曲線に適合させるために利用される場合において、bの帯域幅単位を利用して、サイズsize(o)のコンテンツoの検索時間を、ret(o)=congestion × size(o)× d(b)、としてモデル化し、
Pは、予備取り出し帯域幅の大きさであり、Bは、前記システムにとって有効な全帯域幅であり、r(t)=(1−σ(P))× u(t)は、少なくとも1つのプロキシサーバー内に記憶されていないコンテンツに対するエンドユーザーブラウザ要求を検索するためにシステムが利用する帯域幅の大きさであり、σ(P)は、帯域幅がPである場合のキャッシュの新しさおよび有効性の数値であり、u(t)は、ユーザーのアクセス速度である場合において、時刻t0において、少なくとも1つのコンテンツプロバイダから取り出したコンテンツについて、少なくとも1つのプロキシサーバーが観察した遅延の量を、ret(P)=congestion((P+r(t0))/B)× r(t0)× d、としてモデル化し、
δret(P)/δP=0を解くことにより、最適の予備取り出し帯域幅割当て値Pを計算し、
少なくとも1つのプロキシサーバーへ、最適の予備取り出し帯域幅割当て値Pを通信する、
ようにプログラムされていることを特徴とするコンテンツ配信サービスプロバイダ。 - 前記コンテンツ配信サービスプロバイダは、
Pについて、現在の帯域幅消費量(R=r(t0))を利用して、δret(P)/δP=0を解き、
現在の帯域幅消費量(R=r(t0))を利用して、ret(P)を計算し、
pが今後の参照の度合である場合に、時刻t0までのr(t)の性質を示す履歴関数hr(t)を利用して、期間[t0,t0+ret(P)×p]内の最大の帯域幅消費量Rmaxを推定し、
最大の帯域幅消費量の推定値(R=Rmax)を利用してδret(P)/δP=0を解くことによって、調整済みの予備取り出し帯域幅割当ての数値Padjustedを計算し、
少なくとも1つのプロキシサーバーに対して、調整済みの予備取り出し帯域幅割当ての数値Padjustedを通信する、
ことにより、最悪の場合の帯域幅利用の推定値を考慮に入れる調整済みの予備取り出し帯域幅割当ての数値を計算するように、さらにプログラムされていることを特徴とする請求項1に記載のコンテンツ配信サービスプロバイダ。 - 前記コンテンツ配信サービスプロバイダは、
最大の帯域幅消費量の推定値(Rmax)を利用して、Δt=ret(Padjusted)×pを計算し、
UtilavgおよびPavgを利用して、予想検索時間Retexp(Pavg)を定義することにより、δretexp(Pavg)/δPavg=0を解くことによって、推定的な平均予備取り出し帯域幅割当ての数値Pavgを計算し、
少なくとも1つのプロキシサーバーに対して、前記平均予備取り出し帯域幅割当ての数値Pavgを通信する、
ことにより、平均帯域幅利用の推定値を考慮に入れる平均予備取り出し帯域幅割当ての数値を計算するように、さらにプログラムされていることを特徴とする請求項2に記載のコンテンツ配信サービスプロバイダ。 - 前記コンテンツ配信サービスプロバイダは、
各コンテンツOIに対する、問い合わせ頻度(Oi)、更新頻度(Oi)および期限切れ時間(Oi)は、キャッシュログファイルから入手され、c1、c2およびc3は、前の期間からの統計または一定の時間間隔における経験的計算を利用して割り当てることができる配列係数である場合において、コンテンツOIを予備取り出しするための優先順位の数値を、
計算した優先順位の数値と、所与の予備取り出し帯域幅とを利用して、次のΔt単位時間内に予備取り出しする一組のコンテンツOpを選択し、
少なくとも1つのプロキシサーバーに対して、この一組のコンテンツOpを通信する、 ように、さらにプログラムされていることを特徴とする請求項1に記載のコンテンツ配信サービスプロバイダ。 - 前記コンテンツ配信サービスプロバイダは、
size(oi)は、すべてのoi∈Oに対するサイズであり、Pは、予備取り出し帯域幅である場合において、真のステートメントとして、
少なくとも1つのプロキシサーバーに対して、この一組のコンテンツOpを通信する、 ように、さらにプログラムされていることを特徴とする請求項1に記載のコンテンツ配信サービスプロバイダ。 - 前記コンテンツ配信サービスプロバイダは、
Δt時間単位中における、オブジェクトoiに対する予想アクセス回数は、Δt×q(oi)であり、
少なくとも1つのプロキシサーバーに対して、この一組のコンテンツOpを通信する、 ように、さらにプログラムされていることを特徴とする請求項1に記載のコンテンツ配信サービスプロバイダ。 - コンテンツを記憶し、配信するためのシステムであって、コンテンツを要求するための複数のエンドユーザーブラウザと、コンテンツを配信するための少なくとも1つのコンテンツプロバイダオリジナルサイトと、通信用のネットワークにより相互に接続している、コンテンツを記憶するための少なくとも1つのプロキシサーバーとを含むシステムにおいて、
予備取り出し接続の数を使用して、少なくとも1つのプロキシサーバーに、少なくとも1つのコンテンツプロバイダオリジナルサイトからコンテンツを予備取り出しさせるためのコンテンツ配信サービスプロバイダであって、該コンテンツ配信サービスプロバイダは、
congestion(Util)は、congestion(Util)=β/(Utilθ+α)+φ、または、congestion(Util)=β× (1.0 - Util)α+φ、として表すことができる混雑関数であり、Utilは、許可された接続の最大数に対して開放されている接続の比率を表し、パラメータα、β、およびφが、前記混雑関数をシステムリソース利用と応答遅延との関係を示す混雑曲線に適合させるために利用される場合において、サイズsize(o)のコンテンツoの検索時間を、ret(o)=congestion × size(o)、としてモデル化し、
Pは、予備取り出し接続の数であり、Bは、許可された接続の最大数であり、r(t)=(1−σ(P))×u(t)は、少なくとも1つのプロキシサーバー内に記憶されていないコンテンツを要求により取り出すために、前記システムが利用する接続の数であり、σ(P)は、帯域幅がPである場合のキャッシュの新しさおよび有効性の数値であり、u(t)は、ユーザー接続アクセス速度である場合において、時刻t0において、少なくとも1つのコンテンツプロバイダオリジナルサイトから取り出したコンテンツについて、少なくとも1つのプロキシサーバーにおいて観察された遅延の量を、ret(P)=congestion((P+r(t0)+u(t0))/B)×(u(t0)+r(t0))× 平均的オブジェクトサイズ、としてモデル化し、
δret(P)/δP=0を解くことにより、最適の予備取り出し接続数Pを計算し、
少なくとも1つのプロキシサーバーへ、最適の予備取り出し接続数Pを通信する、
ようにプログラムされていることを特徴とするコンテンツ配信サービスプロバイダ。 - 前記コンテンツ配信サービスプロバイダは、
Pについて、現在の使用接続数(R=r(t0))を利用して、δret(P)/δP=0を解き、
RおよびPを使用して計算した前記混雑を利用して、Pのコンテンツを予備取り出しするために必要な時間の長さρを見出すことにより、pは、Pのコンテンツを予備取り出しするのに必要な時間である場合において、時刻t0までのr(t)の性質を示す履歴関数hr(t)を利用して、期間[t0,t0+p]内における要求による取り出し接続の最大数Rmaxを推定し、
要求による取り出し接続の最大数の推定値(R=Rmax)を利用して、δret(P)/δP=0を解くことにより、調整済みの予備取り出し接続数Padjustedを計算し、
少なくとも1つのプロキシサーバーに対して、調整済みの予備取り出し接続数Padjustedを通信する、
ことにより、最悪の場合の接続利用の推定値を考慮に入れる調整済みの予備取り出し接続数を計算するように、さらにプログラムされていることを特徴とする請求項7に記載のコンテンツ配信サービスプロバイダ。 - 前記コンテンツ配信サービスプロバイダは、
Δtを、Padjustedの接続を予備取り出しするために必要な、最悪の場合の時間の長さとして定義し、
UtilavgおよびPavgを使用して、予想検索時間Retexp(Pavg)を定義し、
δretexp(Pavg)/δPavg=0を解くことによって、平均的な予備取り出し接続数の推定値Pavgを計算し、
少なくとも1つのプロキシサーバーに対して、平均的な予備取り出し接続数の推定値Pavgを通信する、
ことにより、平均的な接続利用の推定値を考慮に入れる平均的な予備取り出し接続数を計算するように、さらにプログラムされていることを特徴とする請求項8に記載のコンテンツ配信サービスプロバイダ。 - 前記コンテンツ配信サービスプロバイダは、
各コンテンツOIに対する、問い合わせ頻度(Oi)、更新頻度(Oi)および期限切れ時間(Oi)は、キャッシュログファイルから入手され、c1、c2およびc3は、前の期間からの統計または一定の時間間隔における経験的計算を利用して割り当てることができる配列係数である場合において、コンテンツOIを予備取り出しするための優先順位の数値を、
計算した優先順位の数値と、所与のネットワーク接続の数とを利用して、次のΔt単位時間内に予備取り出しするための一組のコンテンツOpを選択し、
少なくとも1つのプロキシサーバーに対して、この一組のコンテンツOpを通信する、
ように、さらにプログラムされていることを特徴とする請求項7に記載のコンテンツ配信サービスプロバイダ。 - 前記コンテンツ配信サービスプロバイダは、
size(oi)は、すべてのoi∈Oに対するサイズであり、Pは、予備取り出し帯域幅である場合において、真のステートメントとして、
少なくとも1つのプロキシサーバーに対して、この一組のコンテンツOpを通信する、 ように、さらにプログラムされていることを特徴とする請求項7に記載のコンテンツ配信サービスプロバイダ。 - 前記コンテンツ配信サービスプロバイダは、
Δt時間単位中における、オブジェクトoiに対する予想アクセス回数は、Δt×q(oi)であり、
size(oi)は、すべてのoi∈Oに対するサイズであり、Pは、予備取り出し帯域幅である場合において、真のステートメントとして、
少なくとも1つのプロキシサーバーに対して、この一組のコンテンツOpを通信する、
ように、さらにプログラムされていることを特徴とする請求項7に記載のコンテンツ配信サービスプロバイダ。 - コンテンツを記憶し、配信するためのシステムであって、コンテンツを要求するための複数のエンドユーザーブラウザと、コンテンツを配信するための少なくとも1つのコンテンツプロバイダオリジナルサイトと、通信用のネットワークにより相互に接続している、コンテンツを記憶するための少なくとも1つのプロキシサーバーとを含むシステムにおいて、
予備取り出し帯域幅割当て値を使用して、少なくとも1つのコンテンツプロバイダオリジナルサイトからコンテンツを予備取り出しするため方法であって、該方法は、
d(b)は、bの帯域幅単位が前記コンテンツを予備取り出しするために利用された場合に観察された単位遅延であり、congestion(Util)は、congestion(Util)=β/(Utilθ+α)+φ、または、congestion(Util)=β× (1.0 - Util)α+φ、として表すことができる混雑関数であり、Utilは、最大ネットワーク帯域幅に対して利用されるネットワーク帯域幅の比率を表し、パラメータα、β、およびφが、前記混雑関数を帯域幅利用比率と応答遅延との関係を示す混雑曲線に適合させるために利用される場合において、bの帯域幅単位を利用して、サイズsize(o)のコンテンツoの検索時間を、ret(o)=congestion × size(o)× d(b)、としてモデル化する段階と、
Pは、予備取り出し帯域幅の大きさであり、Bは、前記システムにとって有効な全帯域幅であり、r(t)=(1−σ(P))×u(t)は、少なくとも1つのプロキシサーバー内に記憶されていないコンテンツに対するエンドユーザーブラウザ要求を検索するためにシステムが利用する帯域幅の大きさであり、σ(P)は、帯域幅がPである場合のキャッシュの新しさおよび有効性の数値であり、u(t)は、ユーザーの接続アクセス速度である場合において、時刻t0において、少なくとも1つのコンテンツプロバイダオリジナルサイトから取り出したコンテンツについて、少なくとも1つのプロキシサーバーが観察した遅延の量を、ret(P)=congestion((P+r(t0))/B)×r(t0)×d、としてモデル化する段階と、
δret(P)/δP=0を解くことにより、最適の予備取り出し帯域幅割当ての数値Pを計算する段階と、
最適の予備取り出し帯域幅割当ての数値Pを利用して、少なくとも1つのコンテンツプロバイダオリジナルサイトからコンテンツを予備取り出しする段階と
を含むことを特徴とする方法。 - 前記方法は、さらに、最悪の場合の帯域幅利用の推定値を考慮に入れる調整済みの予備取り出し帯域幅割当ての数値を計算するためのものであって、該方法は、さらに、
Pについて、現在の帯域幅消費量(R=r(t0))を利用して、δret(P)/δP=0を解く段階と、
現在の帯域幅消費量(R=r(t0))を利用して、ret(P)を計算する段階と、
pが今後の参照の度合である場合に、時刻t0までのr(t)の性質を示す履歴関数hr(t)を利用して、期間[t0,t0+ret(P)×p]内の最大の帯域幅消費量Rmaxを推定する段階と、
最大の帯域幅消費量の推定値(R=Rmax)を利用してδret(P)/δP=0を解くことにより、調整済みの予備取り出し帯域幅割当ての数値Padjustedを計算する段階と、
調整済みの予備取り出し帯域幅割当ての数値Padjustedを利用して、少なくとも1つのコンテンツプロバイダオリジナルサイトからコンテンツを予備取り出しする段階と
を含むことを特徴とする請求項13に記載の予備取り出し帯域幅割当て値を利用して、少なくとも1つのコンテンツプロバイダオリジナルサイトからコンテンツを予備取り出しするための方法。 - 前記方法は、さらに、平均帯域幅利用の推定値を考慮に入れる平均予備取り出し帯域幅割当ての数値を計算するためのものであって、該方法は、さらに、
最大の帯域幅消費量の推定値Rmax)を利用して、Δt=ret(Padjusted)を計算する段階と、
UtilavgおよびPavgを利用して、予想検索時間Retexp(Pavg)を定義する段階と、
δretexp(Pavg)/δPavg=0を解くことによって、推定的な平均予備取り出し帯域幅割当ての数値Pavgを計算する段階と、
前記平均予備取り出し帯域幅割当ての数値Pavgを利用して、少なくとも1つのコンテンツプロバイダオリジナルサイトからコンテンツを予備取り出しする段階と
を含むことを特徴とする請求項14記載の予備取り出し帯域幅割当て値を利用して、少なくとも1つのコンテンツプロバイダオリジナルサイトからコンテンツを予備取り出しするための方法。 - 前記方法は、
各コンテンツOIに対する、問い合わせ頻度(Oi)、更新頻度(Oi)および期限切れ時間(Oi)は、キャッシュログファイルから入手され、c1、c2およびc3は、前の期間からの統計または一定の時間間隔における経験的計算を利用して割り当てることができる配列係数である場合において、コンテンツOIを予備取り出しするための優先順位の数値を、
計算した優先順位の数値と、所与の予備取り出し帯域幅とを利用して、次のΔt単位時間内に予備取り出しする一組のコンテンツOpを選択する段階と、
少なくとも1つのプロキシサーバーに対して、この一組のコンテンツOpを通信する段階と
をさらに含むことを特徴とする請求項13に記載の方法。 - 前記方法は、
一組のコンテンツOpから、次のΔt時間単位内に、少なくとも1つのコンテンツプロバイダオリジナルサイトからコンテンツを予備取り出しする段階と
をさらに含むことを特徴とする請求項13に記載の方法。 - 前記方法は、
Δt時間単位中における、オブジェクトoiに対する予想アクセス回数は、Δt×q(oi)であり、
size(oi)は、すべてのoi∈Oに対するサイズであり、Pは、予備取り出し帯域幅である場合において、真のステートメントとして、
一組のコンテンツOpから、次のΔt時間単位内に、少なくとも1つのコンテンツプロバイダオリジナルサイトからコンテンツを予備取り出しする段階と
をさらに含むことを特徴とする請求項13に記載の方法。 - コンテンツを記憶し、配信するためのシステムであって、コンテンツを要求するための複数のエンドユーザーブラウザと、コンテンツを配信するための少なくとも1つのコンテンツプロバイダオリジナルサイトと、通信用のネットワークにより相互に接続している、コンテンツを記憶するための少なくとも1つのプロキシサーバーとを含むシステムにおいて、
予備取り出し接続の数を使用して、少なくとも1つのプロキシサーバーに、少なくとも1つのコンテンツプロバイダオリジナルサイトからコンテンツを予備取り出しさせるための方法であって、該方法は、
congestion(Util)は、congestion(Util)=β/(Utilθ+α)+φ、または、congestion(Util)=β× (1.0 - Util)α+φ、として表すことができる混雑関数であり、Utilは、許可された接続の最大数に対して開放されている接続の比率を表し、パラメータα、β、およびφが、前記混雑関数を統計的に得られたシステムリソース利用と応答遅延との関係を示す混雑曲線に適合させるために利用される場合において、サイズsize(o)のコンテンツoの検索時間を、ret(o)=congestion × size(o)、としてモデル化する段階と、
Pは、予備取り出し接続の数であり、Bは、許可された接続の最大数であり、r(t)=(1−σ(P))×u(t)は、少なくとも1つのプロキシサーバー内に記憶されていないコンテンツを要求により取り出すために、前記システムが利用する接続の数であり、σ(P)は、帯域幅がPである場合の、キャッシュの新しさおよび有効性の数値であり、u(t)は、ユーザー接続アクセス速度である場合において、時刻t0において、少なくとも1つのコンテンツプロバイダオリジナルサイトから取り出したコンテンツについて、少なくとも1つのプロキシサーバーにおいて観察された遅延の量を、ret(P)=congestion((P+r(t0)+u(t0))/B)×(u(t0)+r(t0))×平均的オブジェクトサイズ、としてモデル化する段階と、
δret(P)/δP=0を解くことにより、最適の予備取り出し接続数Pを計算する段階と、最適の予備取り出し接続数Pを使用して、少なくとも1つのコンテンツプロバイダオリジナルサイトからコンテンツを予備取り出しする段階と
を含むことを特徴とする方法。 - 前記方法は、さらに、最悪の場合の接続利用の推定値を考慮に入れる調整済みの予備取り出し接続数を計算するためのものであって、該方法は、さらに、
Pについて、現在の使用接続数(R=r(t0))を利用して、δret(P)/δP=0を解く段階と、
RおよびPを使用して計算した前記混雑を利用して、Pのコンテンツを予備取り出しするために必要な時間の長さρを見出す段階と、
pは、Pのコンテンツを予備取り出しするのに必要な時間である場合において、時刻t0までのr(t)の性質を示す履歴関数hr(t)を使用して、期間[t0,t0+p]内における要求による取り出し接続の最大数Rmaxを推定する段階と、
要求による取り出し接続の最大数の推定値(R=Rmax)を利用して、δret(P)/δP=0を解くことにより、調整済みの予備取り出し接続数Padjustedを計算する段階と、
最適の予備取り出し接続数Padjustedを利用して、少なくとも1つのコンテンツプロバイダオリジナルサイトからコンテンツを予備取り出しする段階と
を含むことを特徴とする請求項19に記載の予備取り出し接続の数を使用して、少なくとも1つのプロキシサーバーに、少なくとも1つのコンテンツプロバイダオリジナルサイトからコンテンツを予備取り出しさせるための方法。 - 前記方法が、さらに、平均的な接続利用の推定値を考慮に入れる平均的な予備取り出し接続数を計算するためのものであって、該方法が、さらに、
Δtを、Padjustedの接続を予備取り出しするために必要な、最悪の場合の時間の長さとして定義する段階と、
UtilavgおよびPavgを使用して、予想検索時間Retexp(Pavg)を定義する段階と、
δretexp(Pavg)/δPavg=0を解くことによって、平均的な予備取り出し接続数の推定値Pavgを計算する段階と、
平均的な予備取り出し接続数Pavgにより、少なくとも1つのコンテンツプロバイダオリジナルサイトからコンテンツを予備取り出しする段階と
を含む請求項20に記載の予備取り出し接続の数を使用して、少なくとも1つのプロキシサーバーに、少なくとも1つのコンテンツプロバイダオリジナルサイトからコンテンツを予備取り出しさせるための方法。 - 前記方法は、
各コンテンツOIに対する、問い合わせ頻度(Oi)、更新頻度(Oi)および期限切れ時間(Oi)は、キャッシュログファイルから入手され、c1、c2およびc3は、前の期間からの統計または一定の時間間隔における経験的計算を利用して割り当てることができる配列係数である場合において、コンテンツOIを予備取り出しするための優先順位の数値を、
計算した優先順位の数値と、所与のネットワーク接続の数とを利用して、次のΔt単位時間内に予備取り出しするための一組のコンテンツOpを選択する段階と、
少なくとも1つのプロキシサーバーに対して、この一組のコンテンツOpを通信する段階と
をさらに含むことを特徴とする請求項19に記載の方法。 - 前記方法は、
size(oi)は、すべてのoi∈Oに対するサイズであり、Pは、予備取り出し帯域幅である場合において、真のステートメントとして、
一組のコンテンツOpから、次のΔ単位時間内に、少なくとも1つのコンテンツプロバイダオリジナルサイトからコンテンツを予備取り出しする段階と
をさらに含むことを特徴とする請求項19に記載の方法。 - 前記方法は、
Δt時間単位中における、オブジェクトoiに対する予想アクセス回数は、Δt×q(oi)であり、
size(oi)は、すべてのoi∈Oに対するサイズであり、Pは、予備取り出し帯域幅である場合において、真のステートメントとして、
一組のコンテンツOpから、次のΔ単位時間内に、少なくとも1つのコンテンツプロバイダオリジナルサイトからコンテンツを予備取り出しする段階と
をさらに含むことを特徴とする請求項19に記載の方法。
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US19564100P | 2000-04-07 | 2000-04-07 | |
US195.641 | 2000-08-31 | ||
US09/654,106 US6701316B1 (en) | 2000-04-07 | 2000-08-31 | Method and apparatus for intelligent network bandwidth and system resource utilization for web content fetch and refresh |
US654.106 | 2000-08-31 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2001292173A JP2001292173A (ja) | 2001-10-19 |
JP3575428B2 true JP3575428B2 (ja) | 2004-10-13 |
Family
ID=26891171
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2001019771A Expired - Fee Related JP3575428B2 (ja) | 2000-04-07 | 2001-01-29 | インテリジェントネットワーク帯域幅およびシステムリソースを使用するための方法および装置 |
Country Status (2)
Country | Link |
---|---|
US (1) | US6701316B1 (ja) |
JP (1) | JP3575428B2 (ja) |
Families Citing this family (97)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8156074B1 (en) * | 2000-01-26 | 2012-04-10 | Synchronoss Technologies, Inc. | Data transfer and synchronization system |
US8620286B2 (en) * | 2004-02-27 | 2013-12-31 | Synchronoss Technologies, Inc. | Method and system for promoting and transferring licensed content and applications |
US6671757B1 (en) * | 2000-01-26 | 2003-12-30 | Fusionone, Inc. | Data transfer and synchronization system |
US6920110B2 (en) * | 2001-02-14 | 2005-07-19 | Microsoft Corporation | System and method for transferring data over a network |
US7437428B1 (en) | 2000-02-16 | 2008-10-14 | Microsoft Corporation | System and method for transferring data over a network |
US20050055426A1 (en) * | 2000-06-12 | 2005-03-10 | Kim Smith | System, method and computer program product that pre-caches content to provide timely information to a user |
US7401118B1 (en) * | 2000-07-19 | 2008-07-15 | Hitachi, Ltd. | Web information preferential transfer system |
US8073954B1 (en) | 2000-07-19 | 2011-12-06 | Synchronoss Technologies, Inc. | Method and apparatus for a secure remote access system |
US7895334B1 (en) | 2000-07-19 | 2011-02-22 | Fusionone, Inc. | Remote access communication architecture apparatus and method |
US6959438B2 (en) * | 2000-12-06 | 2005-10-25 | Microsoft Corporation | Interface and related methods for dynamically generating a filter graph in a development system |
US7287226B2 (en) | 2000-12-06 | 2007-10-23 | Microsoft Corporation | Methods and systems for effecting video transitions represented by bitmaps |
US6834390B2 (en) * | 2000-12-06 | 2004-12-21 | Microsoft Corporation | System and related interfaces supporting the processing of media content |
US7114162B2 (en) * | 2000-12-06 | 2006-09-26 | Microsoft Corporation | System and methods for generating and managing filter strings in a filter graph |
US6774919B2 (en) * | 2000-12-06 | 2004-08-10 | Microsoft Corporation | Interface and related methods for reducing source accesses in a development system |
US7114161B2 (en) | 2000-12-06 | 2006-09-26 | Microsoft Corporation | System and related methods for reducing memory requirements of a media processing system |
US6882891B2 (en) * | 2000-12-06 | 2005-04-19 | Microsoft Corporation | Methods and systems for mixing digital audio signals |
US6961943B2 (en) * | 2000-12-06 | 2005-11-01 | Microsoft Corporation | Multimedia processing system parsing multimedia content from a single source to minimize instances of source files |
US6954581B2 (en) * | 2000-12-06 | 2005-10-11 | Microsoft Corporation | Methods and systems for managing multiple inputs and methods and systems for processing media content |
US6768499B2 (en) * | 2000-12-06 | 2004-07-27 | Microsoft Corporation | Methods and systems for processing media content |
US6983466B2 (en) * | 2000-12-06 | 2006-01-03 | Microsoft Corporation | Multimedia project processing systems and multimedia project processing matrix systems |
US7447754B2 (en) * | 2000-12-06 | 2008-11-04 | Microsoft Corporation | Methods and systems for processing multi-media editing projects |
US6912717B2 (en) * | 2000-12-06 | 2005-06-28 | Microsoft Corporation | Methods and systems for implementing dynamic properties on objects that support only static properties |
US7103677B2 (en) * | 2000-12-06 | 2006-09-05 | Microsoft Corporation | Methods and systems for efficiently processing compressed and uncompressed media content |
US7818435B1 (en) * | 2000-12-14 | 2010-10-19 | Fusionone, Inc. | Reverse proxy mechanism for retrieving electronic content associated with a local network |
US7003572B1 (en) * | 2001-02-28 | 2006-02-21 | Packeteer, Inc. | System and method for efficiently forwarding client requests from a proxy server in a TCP/IP computing environment |
US8615566B1 (en) | 2001-03-23 | 2013-12-24 | Synchronoss Technologies, Inc. | Apparatus and method for operational support of remote network systems |
JP2002288105A (ja) * | 2001-03-26 | 2002-10-04 | Hitachi Ltd | ストレージエリアネットワークシステム、その運用方法、ストレージ、データ転送量監視装置 |
GB2373882B (en) * | 2001-03-27 | 2005-07-27 | Proksim Software Inc | Comparing the position of shared objects |
US20020188717A1 (en) * | 2001-06-08 | 2002-12-12 | International Business Machines Corporation | Method and apparatus for modeling the performance of Web page retrieval |
US7054416B2 (en) * | 2001-09-24 | 2006-05-30 | Meyerson Robert F | Modular multi-media communication management system |
US20030115281A1 (en) * | 2001-12-13 | 2003-06-19 | Mchenry Stephen T. | Content distribution network server management system architecture |
US6925461B2 (en) * | 2001-12-17 | 2005-08-02 | At&T Corp. | Parallel random proxy usage for large scale web access |
US8635305B1 (en) * | 2001-12-19 | 2014-01-21 | Cisco Technology, Inc. | Mechanisms for providing differentiated services within a web cache |
US7076544B2 (en) * | 2002-04-08 | 2006-07-11 | Microsoft Corporation | Caching techniques for streaming media |
GB0221328D0 (en) * | 2002-09-13 | 2002-10-23 | British Telecomm | Media article composition |
US6959374B2 (en) * | 2003-01-29 | 2005-10-25 | Sun Microsystems, Inc. | System including a memory controller configured to perform pre-fetch operations including dynamic pre-fetch control |
JP4485141B2 (ja) | 2003-04-10 | 2010-06-16 | 株式会社日立製作所 | ネットワーク上のサービス公開及び提供方法並びにそのプログラム |
US20040230753A1 (en) * | 2003-05-16 | 2004-11-18 | International Business Machines Corporation | Methods and apparatus for providing service differentiation in a shared storage environment |
US8645471B2 (en) * | 2003-07-21 | 2014-02-04 | Synchronoss Technologies, Inc. | Device message management system |
GB0406860D0 (en) | 2004-03-26 | 2004-04-28 | British Telecomm | Computer apparatus |
US20050251495A1 (en) * | 2004-05-06 | 2005-11-10 | Bea Systems, Inc. | System and method for unified file management |
US20080082421A1 (en) * | 2004-05-12 | 2008-04-03 | Richard Onyon | Monetization of an advanced contact identification system |
EP1759521B1 (en) * | 2004-05-12 | 2016-06-29 | Synchronoss Technologies, Inc. | Advanced contact identification system |
US9542076B1 (en) | 2004-05-12 | 2017-01-10 | Synchronoss Technologies, Inc. | System for and method of updating a personal profile |
US8224964B1 (en) | 2004-06-30 | 2012-07-17 | Google Inc. | System and method of accessing a document efficiently through multi-tier web caching |
US8676922B1 (en) | 2004-06-30 | 2014-03-18 | Google Inc. | Automatic proxy setting modification |
US7437364B1 (en) * | 2004-06-30 | 2008-10-14 | Google Inc. | System and method of accessing a document efficiently through multi-tier web caching |
US10748158B2 (en) | 2004-10-08 | 2020-08-18 | Refinitiv Us Organization Llc | Method and system for monitoring an issue |
US7957379B2 (en) * | 2004-10-19 | 2011-06-07 | Nvidia Corporation | System and method for processing RX packets in high speed network applications using an RX FIFO buffer |
WO2006125112A2 (en) * | 2005-05-19 | 2006-11-23 | Fusionone, Inc. | Remote cell phone auto destruct |
US10825029B2 (en) * | 2005-09-09 | 2020-11-03 | Refinitiv Us Organization Llc | Subscription apparatus and method |
KR20090113310A (ko) * | 2007-01-26 | 2009-10-29 | 퓨전원 인코포레이티드 | 모바일 디바이스에서 사용하기 위한 콘텐츠를 백업하는 시스템 및 방법 |
US8812651B1 (en) | 2007-02-15 | 2014-08-19 | Google Inc. | Systems and methods for client cache awareness |
US8239345B2 (en) * | 2007-12-27 | 2012-08-07 | Microsoft Corporation | Asynchronous replication |
US8181111B1 (en) | 2007-12-31 | 2012-05-15 | Synchronoss Technologies, Inc. | System and method for providing social context to digital activity |
EP2274889B1 (en) * | 2008-05-07 | 2012-03-28 | Telefonaktiebolaget L M Ericsson (PUBL) | System for delivery of content to be played autonomously |
US7941538B2 (en) * | 2008-06-12 | 2011-05-10 | International Business Machines Corporation | Dynamic management of resource utilization |
US7975025B1 (en) * | 2008-07-08 | 2011-07-05 | F5 Networks, Inc. | Smart prefetching of data over a network |
US9270748B2 (en) | 2008-12-18 | 2016-02-23 | Telefonaktiebolaget L M Ericsson (Publ) | Method for content delivery involving a policy database |
US9369516B2 (en) | 2009-01-13 | 2016-06-14 | Viasat, Inc. | Deltacasting |
US8483217B2 (en) | 2009-03-10 | 2013-07-09 | Viasat, Inc. | Internet protocol broadcasting |
US8874694B2 (en) * | 2009-08-18 | 2014-10-28 | Facebook, Inc. | Adaptive packaging of network resources |
US8255006B1 (en) | 2009-11-10 | 2012-08-28 | Fusionone, Inc. | Event dependent notification system and method |
US8516253B1 (en) | 2010-01-18 | 2013-08-20 | Viasat, Inc. | Self-keyed protection of anticipatory content |
US8880467B1 (en) | 2010-03-29 | 2014-11-04 | Google Inc. | Smart sync—refreshing application state based on user migration patterns |
US9043385B1 (en) | 2010-04-18 | 2015-05-26 | Viasat, Inc. | Static tracker |
US9680766B2 (en) | 2010-09-28 | 2017-06-13 | Ohio State Innovation Foundation | Predictive network system and method |
US8943428B2 (en) | 2010-11-01 | 2015-01-27 | Synchronoss Technologies, Inc. | System for and method of field mapping |
US8484293B2 (en) | 2010-12-30 | 2013-07-09 | International Business Machines Corporation | Managing delivery of electronic meeting content |
US8156239B1 (en) | 2011-03-09 | 2012-04-10 | Metropcs Wireless, Inc. | Adaptive multimedia renderer |
US9456050B1 (en) | 2011-04-11 | 2016-09-27 | Viasat, Inc. | Browser optimization through user history analysis |
US9037638B1 (en) | 2011-04-11 | 2015-05-19 | Viasat, Inc. | Assisted browsing using hinting functionality |
US9912718B1 (en) | 2011-04-11 | 2018-03-06 | Viasat, Inc. | Progressive prefetching |
US11983233B2 (en) | 2011-04-11 | 2024-05-14 | Viasat, Inc. | Browser based feedback for optimized web browsing |
EP2512101B1 (en) | 2011-04-11 | 2014-05-07 | Deutsche Telekom AG | Method and system to pre-fetch user-specific HTTP requests for web applications |
US9106607B1 (en) | 2011-04-11 | 2015-08-11 | Viasat, Inc. | Browser based feedback for optimized web browsing |
EP2536065B1 (en) | 2011-06-14 | 2019-11-27 | ViaSat, Inc. | Transport protocol for anticipatory content |
CN102857483B (zh) * | 2011-06-30 | 2016-06-29 | 国际商业机器公司 | 预取数据的方法、设备和装置 |
US9407355B1 (en) | 2011-10-25 | 2016-08-02 | Viasat Inc. | Opportunistic content delivery using delta coding |
US9294582B2 (en) | 2011-12-16 | 2016-03-22 | Microsoft Technology Licensing, Llc | Application-driven CDN pre-caching |
US8432808B1 (en) | 2012-06-15 | 2013-04-30 | Viasat Inc. | Opportunistically delayed delivery in a satellite network |
CN111614980B (zh) | 2012-08-14 | 2022-04-12 | 俄亥俄州立创新基金会 | 用于通过移动设备来优化网络带宽的使用的系统和方法 |
US10841352B2 (en) * | 2012-11-27 | 2020-11-17 | International Business Machines Corporation | Non-chronological buffering of segments of a media file |
US9357021B2 (en) * | 2013-03-14 | 2016-05-31 | Comcast Cable Communications, Llc | Delivery of content |
US9009103B2 (en) * | 2013-03-15 | 2015-04-14 | Microsoft Technology Licensing, Llc | Fingerprint-based, intelligent, content pre-fetching |
US9304928B2 (en) * | 2013-07-26 | 2016-04-05 | Netapp, Inc. | Systems and methods for adaptive prefetching |
US9326026B2 (en) * | 2013-10-31 | 2016-04-26 | At&T Intellectual Property I, Lp | Method and apparatus for content distribution over a network |
US9444905B2 (en) * | 2014-03-20 | 2016-09-13 | International Business Machines Corporation | Allocating network bandwidth to prefetch requests to prefetch data from a remote storage to cache in a local storage |
WO2015147354A1 (ko) * | 2014-03-27 | 2015-10-01 | 엘지전자 주식회사 | Spdy에 기초한 웹 가속 방법 및 이를 위한 spdy 프록시 |
US10855797B2 (en) | 2014-06-03 | 2020-12-01 | Viasat, Inc. | Server-machine-driven hint generation for improved web page loading using client-machine-driven feedback |
EP3365802A1 (en) | 2015-10-20 | 2018-08-29 | Viasat, Inc. | Hint model updating using automated browsing clusters |
US10880272B2 (en) * | 2017-04-20 | 2020-12-29 | Wyse Technology L.L.C. | Secure software client |
CN110545479B (zh) * | 2018-05-29 | 2021-07-06 | 北京字节跳动网络技术有限公司 | 媒体播放的加载控制方法、装置及存储介质 |
WO2020186081A1 (en) * | 2019-03-12 | 2020-09-17 | Intel Corporation | Computational data storage systems |
CN110995523B (zh) * | 2019-10-28 | 2021-11-16 | 国电南瑞科技股份有限公司 | 一种云计算平台容量的快速计算方法 |
AU2020417157A1 (en) * | 2020-01-02 | 2022-07-28 | Level 3 Communications, Llc | Systems and methods for storing content items in secondary storage |
US20230115728A1 (en) * | 2021-10-12 | 2023-04-13 | Centurylink Intellectual Property Llc | Localized subservice system and method to provide improved core network services |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3488289B2 (ja) * | 1994-09-19 | 2004-01-19 | Kddi株式会社 | ハイパーメディア文書通信装置 |
JP3117003B2 (ja) * | 1997-07-03 | 2000-12-11 | 日本電気株式会社 | 広域分散ファイルシステム |
JPH11149405A (ja) * | 1997-11-14 | 1999-06-02 | Hitachi Ltd | Wwwキャッシュシステムおよびwwwデータの先読み方法 |
-
2000
- 2000-08-31 US US09/654,106 patent/US6701316B1/en not_active Expired - Lifetime
-
2001
- 2001-01-29 JP JP2001019771A patent/JP3575428B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2001292173A (ja) | 2001-10-19 |
US6701316B1 (en) | 2004-03-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3575428B2 (ja) | インテリジェントネットワーク帯域幅およびシステムリソースを使用するための方法および装置 | |
US7107406B2 (en) | Method of prefetching reference objects using weight values of referrer objects | |
US6292835B1 (en) | Network bandwidth and object obsolescence sensitive scheduling method and apparatus for objects distributed broadcasting | |
US7130890B1 (en) | Method and system for adaptively prefetching objects from a network | |
JP4294494B2 (ja) | 複数のキャッシュサーバによる共有ストレージの使用を管理するデバイスおよび方法 | |
US6330561B1 (en) | Method and apparatus for improving end to end performance of a data network | |
US6901484B2 (en) | Storage-assisted quality of service (QoS) | |
US6567893B1 (en) | System and method for distributed caching of objects using a publish and subscribe paradigm | |
US8065275B2 (en) | Systems and methods for cache optimization | |
US9888470B2 (en) | Network accelerator for controlled long delay links | |
US20030172236A1 (en) | Methods and systems for distributed caching in presence of updates and in accordance with holding times | |
US20160063577A1 (en) | Handling of real-time advertisement with content prefetching | |
WO2017025052A1 (zh) | 资源缓存方法及装置 | |
GB2391963A (en) | Method and apparatus for preloading caches | |
AU2001281409A1 (en) | Multi-tier caching system | |
CN103916474B (zh) | 缓存时间的确定方法、装置及系统 | |
JP2004516532A (ja) | 多層キャッシングシステム | |
JP5192506B2 (ja) | ファイルキャッシュの管理方法、装置、及び、プログラム | |
US6915386B2 (en) | Processing service level agreement (SLA) terms in a caching component of a storage system | |
JP6146279B2 (ja) | データ配信装置及びデータ配信方法 | |
EP2317727A1 (en) | Method for cache management and devices therefore | |
Yu et al. | A new prefetch cache scheme | |
Cheng et al. | Improving web server performance with adaptive proxy caching in soft real-time mobile applications | |
KR100647419B1 (ko) | 데이터 통신을 위한 예측적인 데이터 캐쉬 방법 | |
Feng et al. | A Matrix Algorithm forWeb Cache Pre-fetching |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20040212 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040316 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040517 |
|
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: 20040615 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040628 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20070716 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080716 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090716 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100716 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110716 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110716 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120716 Year of fee payment: 8 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120716 Year of fee payment: 8 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130716 Year of fee payment: 9 |
|
LAPS | Cancellation because of no payment of annual fees |