HTTP プロキシーキャッシュ

HTTP プロキシーキャッシュは頻繁にアクセスされる (ドキュメント、イメージや記事などの) ウェブオブジェクトのコピーを保管することを可能にし、この情報を必要に応じてユーザに配信することを可能にします。これによりパフォーマンスを改善しインターネットのバンド幅を開放して他の作業に使えるようにします。

HTTP ウェブプロキシーキャッシュの理解

インターネットのユーザーはインターネットのいたるところに有るウェブサーバにリクエストを送ります。キャッシュサーバーはこれらのリクエストに応答できるように ウェブプロキシサーバー として振る舞わなければなりません。ウェブプロキシサーバーはウェブオブジェクトへのリクエストを受け取った後、リクエストに応答するかオリジンサーバー (リクエストされた情報の原本を保管しているウェブサーバー) に転送します。 Traffic Server のプロキシーは 明示的なプロキシーキャッシュ をサポートし、ユーザーのクライアントソフトウェアは Traffic Server プロキシーに直接リクエストを送るように設定されなければいけません。以降の概要では Traffic Server がリクエストにどのように応答するかを説明します。

  1. Traffic Server がウェブオブジェクトへのクライアントリクエストを受け取ります。

  2. オブジェクトのアドレスを用いて Traffic Server はリクエストされたオブジェクトがオブジェクトデータベース (キャッシュ) 内に存在するかどうかと、存在する場合はその位置を特定しようとします。

  3. オブジェクトがキャッシュにある場合は、 Traffic Server はオブジェクトが提供するのに十分新鮮かどうかを確認します。新鮮な場合、 Traffic Server はそれを キャッシュヒット としてクライアントに提供します (下図参照)。

    A cache hit

    キャッシュヒット

  4. キャッシュのデータが古い場合、 Traffic Server はオリジンサーバーへ接続し、オブジェクトが依然新しいかどうか確認します。( 再確認 ) 新しい場合、 Traffic Server はすぐにキャッシュしているコピーをクライアントに送ります。

  5. オブジェクトがキャッシュに無い場合 (キャッシュミス) やサーバーがキャッシュしたコピーをもはや有効ではないと判断した場合、 Traffic Server はオリジンサーバーからオブジェクトを取得します。オブジェクトはクライアントと Traffic Server のローカルキャッシュに同時に流されます。(下の図を見てください) 続いて起こるオブジェクトへのリクエストはよりはやく提供することができます。それはオブジェクトがキャッシュから直接検索されるからです。

    A cache miss

    キャッシュミス

一般的にキャッシュは前述の概要で説明したものよりも複雑です。 詳しく述べると、概要では Traffic Server がどのように新鮮さを保証し、正しい HTTP オブジェクトの代替を提供し、キャッシュできないもしくはするべきではないオブジェクトへのリクエストを扱うかについて説明されていませんでした。次の章はこれらのことについてとても詳しく説明します。

キャッシュされたオブジェクトの新鮮さの保証

Traffic Server がウェブオブジェクトへのリクエストを受け取った際、最初にリクエストされたオブジェクトをキャッシュから探します。オブジェクトがキャッシュにある場合、 Traffic Server はオブジェクトが提供するのに十分新しいかどうかを確認します。 Traffic Server は HTTP オブジェクトに作成者が指定した有効期限をサポートしています。 Traffic Server はこれらの有効期限を固く守ります。つまり、どれだけ頻繁にオブジェクトが変更されるかと、管理者が選んだフレッシュネスガイドラインに基づいて、有効期限を選択します。オブジェクトはまた、依然として新しいかどうかをオリジンサーバーへ見に行くことにより、再確認されます。

HTTP オブジェクトの新鮮さ

Traffic Server はキャッシュにある HTTP オブジェクトが新鮮かどうかを下記の条件で順番に判定します。

  • Expires max-age ヘッダーの確認

    いくつかの HTTP オブジェクトは Expire ヘッダーや max-age ヘッダーを含んでいます。これらはオブジェクトがどれくらいの期間キャッシュできるかどうかを明確に定義しています。 Traffic Server はオブジェクトが新しいかどうかを決定するために、現在時刻と有効期限を比較します。

  • Last-Modified / Date ヘッダーの確認

    HTTP オブジェクトが Expire ヘッダーや max-age ヘッダーを持っていない場合、 Traffic Server はフレッシュネスリミットを次の式で計算します。

    freshness_limit = ( date - last_modified ) * 0.10
    

    ここで date はオブジェクトのサーバーレスポンスヘッダー内の日時で、 last_modifiedLast-Modified の日時です。 Last-Modified ヘッダーが無い場合は、 Traffic Server はオブジェクトがキャッシュに書かれた日時を使用します。 0.10 (10パーセント) という値はあなたのニーズにより適合するように増やしたり減らしたりすることができます。 新鮮さの計算のための期間要素の変更 を参照してください。

    計算されたフレッシュネスリミットは最小値と最大値に制約されます。詳細は 絶対フレッシュネスリミットの設定 を参照してください。

  • 絶対フレッシュネスリミットの確認

    Expires ヘッダーを持たない HTTP オブジェクトまたは Last-Modified ヘッダーと Date ヘッダーの両方を持たない HTTP オブジェクトに対して Traffic Server は最大と最小のフレッシュネスリミットを使用します。 絶対フレッシュネスリミットの設定 を参照してください。

  • cache.config 内の 再確認ルールを確認

    再確認ルールは特定の HTTP オブジェクトにフレッシュネスリミットを適用します。特定のドメインや IP アドレスから取得されたオブジェクト、特定の正規表現に URL がマッチするオブジェクト、特定のクライアントからリクエストされたオブジェクト、などに対してフレッシュネスリミットを設定することが出来ます。 cache.config を参照してください。

新鮮さの計算のための期間要素の変更

オブジェクトが有効期限に関する情報を持っていない場合、 Traffic Server は Last-ModifiedDate ヘッダーから新鮮さを見積もります。デフォルトでは Traffic Server は最後に更新されてからの経過時間の 10 % キャッシュします。 必要に応じて、増減することができます。

新鮮さの計算のための期間要素を変更するには:

  1. proxy.config.http.cache.heuristic_lm_factor の値を変更してください。
  2. 設定変更を適用するために traffic_ctl config reload コマンドを実行してください。

絶対フレッシュネスリミットの設定

いくつかのオブジェクトは Expires ヘッダーを持っていない、あるいは Last-Modified ヘッダーと Date ヘッダーの両方を持っていません。どれだけの時間がこれらのオブジェクトがキャッシュ内で新鮮と見なされるかを制御するには 絶対フレッシュネスリミット を指定してください。

絶対フレッシュネスリミットを指定するには:

  1. records.config 内の proxy.config.http.cache.heuristic_min_lifetime 変数と proxy.config.http.cache.heuristic_max_lifetime 変数を編集してください。
  2. 設定変更を適用するために traffic_ctl config reload コマンドを実行してください。

必須ヘッダーの記述

よりいっそうキャッシュしているオブジェクトの新鮮さを確かめるために、特定のヘッダーを持っているオブジェクトだけをキャッシュするように Traffic Server を設定することができます。デフォルトでは Traffic Server は(ヘッダーがないものも含む)全てのオブジェクトをキャッシュします。特別なプロキシーの状況の場合のみデフォルト設定を変更するべきです。Traffic Server を Expires もしくは max-age ヘッダーを持つオブジェクトだけをキャッシュするように設定した場合、キャッシュヒット率は明らかに下がるでしょう。(とても少ないオブジェクトしか明確な有効期限の情報をもっていないと考えられるためです。)

Traffic Server に特定のヘッダを持つオブジェクトをキャッシュするように設定するには:

  1. records.config 内の proxy.config.http.cache.required_headers の値を変更してください。
  2. 設定変更を適用するために traffic_ctl config reload コマンドを実行してください。

Cache-Control ヘッダー

キャッシュ内のオブジェクトが新鮮であっても、クライアントかサーバーがキャッシュからオブジェクトを取得することを妨げるような自身の制約を課すことがしばしばあります。例えば、クライアントがキャッシュから取得したのではないオブジェクトをリクエストするかもしれませんし、キャッシュの取得を許可したとしてもオブジェクトは 10 分より長くキャッシュされることは許可されません。

Traffic Server はキャッシュされたオブジェクトを提供か判定するためにクライアントのリクエストヘッダーとサーバーのレスポンスヘッダーの両方に含まれる Cache-Control ヘッダーを調べます。 Cache-Control ヘッダーはオブジェクトをキャッシュから提供するかどうかに以下のように作用します。

  • クライアントからの no-cache ヘッダーは Traffic Server にどんなオブジェクトもキャッシュから直接提供すべきでないことを伝えます。クライアントリクエストに含まれる場合は、 Traffic Server は常にオブジェクトをオリジンサーバーから取得します。 Traffic Server がクライアントの no-cache ヘッダーを無視するように設定することも出来ます。詳細は クライアントの no-cache ヘッダーを無視する Traffic Server の設定 を参照してください。
  • サーバーからの max-age ヘッダーはオブジェクトの経過時間と比べられます。経過時間が max-age より小さければオブジェクトは新鮮であり、 Traffic Server のキャッシュから提供することが出来ます。
  • クライアントからの min-fresh ヘッダーは 受け入れ可能な新鮮さの範囲 です。これはクライアントがオブジェクトは最低でもこの新鮮さを持つことを要求していることを意味します。キャッシュされたオブジェクトが将来最低でもこの新鮮さを保持していなければ、再確認されます。
  • クライアントからの max-stale ヘッダーは Traffic Server に古すぎない失効したオブジェクトを配信することを許可します。いくつかのブラウザーは特に貧弱なインターネット環境にあるような場合パフォーマンスを向上させるため、わずかに失効したオブジェクトを受け取ることを望むかもしれません。

Traffic Server は Cache-Control による提供可能解析を HTTP フレッシュネス解析の後に行います。例えば、オブジェクトが新鮮だと判定されても経過時間が max-age より大きければ提供されないでしょう。

HTTP オブジェクトの再確認

クライアントがリクエストした HTTP オブジェクトがキャッシュにあるが新鮮ではない場合、 Traffic Server はオブジェクトを再確認します。 再確認 とはオリジンサーバーでオブジェクトが変更されていないことを問い合わせることです。再確認の結果は以下のいずれかです:

  • オブジェクトが依然として新鮮な場合、 Traffic Server はフレッシュネスリミットをリセットして、そのオブジェクトを配信します。
  • オブジェクトの新しいコピーが有効な場合、 Traffic Server は新しいオブジェクトをキャッシュします。(従って、新鮮ではないコピーは置き換えられます) また、同時にオブジェクトをクライアントに配信します。
  • オブジェクトがオリジンサーバー上に存在しない場合、 Traffic Server はキャッシュしたコピーを配信しません。
  • オリジンサーバーが再確認の問い合わせに応答しない場合、 Traffic Server は 111 Revalidation Failed 警告と共に新鮮ではないオブジェクトを配信します。

デフォルトでは Traffic Server はリクエストされた HTTP オブジェクトが新鮮ではないと考えられる場合に再確認します。 Traffic Server のオブジェクトの新鮮さの評価については HTTP オブジェクトの新鮮さ で述べられています。次のオプションの一つを選ぶことによって、 Traffic Server が新鮮さを評価する方法を再設定することができます。

Traffic Server considers all HTTP objects in the cache to be stale:
常にキャッシュの中の HTTP オブジェクトをオリジンサーバーへ再確認します。
Traffic Server considers all HTTP objects in the cache to be fresh:
オリジンサーバーへ HTTP オブジェクトを再確認することはありません。
Traffic Server considers all HTTP objects without Expires or Cache-control headers to be stale:
ExpiresCache-Control ヘッダーのない全ての HTTP オブジェクトを再確認します。

Traffic Server がキャッシュしているオブジェクトを再確認する方法を設定するには cache.config に特定の再確認のルールを設定してください。

再確認のオプションを設定するには

  1. records.configproxy.config.http.cache.when_to_revalidate を編集してください。
  2. 設定変更を適用するために traffic_ctl config reload コマンドを実行してください。

コンテンツのキャッシュへのプッシュ

Traffic Server はコンテンツ配信に HTTP PUSH メソッドをサポートして います。HTTP PUSH を使用すると、クライアントからのリクエスト無しに直接コンテンツをキャッシュの中に入れることができます。

PUSH リクエスト用の Traffic Server の設定

HTTP PUSH を使用してコンテンツをキャッシュの中に入れる前に、 Traffic Server が PUSH リクエストを受け入れるように設定する必要があります。

  1. file:ip_allow.config を変更して適切なアドレスからの PUSH を許可してください。

  2. records.configproxy.config.http.push_method_enabled を更新してください

    CONFIG proxy.config.http.push_method_enabled INT 1
    
  3. 設定変更を適用するために traffic_ctl config reload を実行してください。

HTTP PUSH の理解

PUSH は HTTP 1.1 メッセージフォーマットを使用します。 PUSH リクエストのボディはキャッシュに入れたいレスポンスヘッダーとレスポンスボディを含みます。下記は PUSH リクエストの例です。

PUSH http://www.company.com HTTP/1.0
Content-length: 84

HTTP/1.0 200 OK
Content-type: text/html
Content-length: 17

<HTML>
a
</HTML>

重要

あなたの PUSH ヘッダーは Content-Length を含まなければなりません。 Content-Length の値はヘッダーとボディーのバイト数を含まなければなりません。この値は省略可能ではなく、不適切な (大きすぎる、あるいは小さすぎる) 値は望ましくない振る舞いを引き起こします。

プッシュを手助けするツール

Traffic Server にはプッシュのための Perl スクリプト tspush が同梱されており、あなた自身がコンテンツをプッシュするスクリプトをどのように書けばよいかを理解する助けになり得ます。

コンテンツのキャッシュへのピン留め

キャッシュのピン留めオプション は特定の時間の間 HTTP オブジェクトをキャッシュに確実に入れておくように Traffic Server を設定します。最もポピュラーなオブジェクトが必要とされるときにキャッシュされていることと、 Traffic Server が重要なオブジェクトを削除することを防ぐことを確実にしたい際にこのオプションが使えます。 Traffic Server は Cache-Control ヘッダーを監視し、本当にキャッシュ可能な場合にオブジェクトをキャッシュに留めます。

キャッシュを留めるルールを設定するためには

  1. records.configproxy.config.cache.permit.pinning を有効にしてください。

    CONFIG proxy.config.cache.permit.pinning INT 1
    
  2. Traffic Server にキャッシュに留めさせたい URL 毎に cache.config にルールを追加してください。例:

    url_regex=^https?://(www.)?apache.org/dev/ pin-in-cache=12h
    
  3. 設定変更を適用するために traffic_ctl config reload を実行してください。

HTTP オブジェクトのキャッシュ

Traffic Server がキャッシュしていないウェブオブジェクトへのリクエストを受け取った際、オリジンサーバーからオブジェクトを回収し、クライアントに配信します。その際に、 Traffic Server は将来のリクエストに備えてキャッシュに保存する前に、オブジェクトがキャッシュ可能かどうか確認します。

Traffic Server は設定オプションやファイルに指定したディレクティブと同じように、クライアントやオリジンサーバーからのキャッシュのディレクティブに反応します。

クライアントディレクティブ

デフォルトでは Traffic Server は次のリクエストヘッダーを持つオブジェクトをキャッシュしません。

  • Authorization

  • Cache-Control: no-store

  • Cache-Control: no-cache

    このリクエストヘッダーを無視するように Traffic Server を設定するには クライアントの no-cache ヘッダーを無視する Traffic Server の設定 を参照してください。

  • Cookie (テキストオブジェクトに対して)

    By default, Traffic Server caches objects served in response to requests that contain cookies (even if the object is text). You can configure Traffic Server to not cache cookied content of any type, cache all cookied content, or cache cookied content that is of image type only. For more information, refer to Caching Cookied Objects.

クライアントの no-cache ヘッダーを無視する Traffic Server の設定

デフォルトでは Traffic Server はクライアントの Cache-Control: no-cache ディレクティブを正確に守ります。リクエストされたオブジェクトが no-cache を含んでいる場合、 Traffic Server はキャッシュのコピーが新鮮であったとしても、オリジンサーバーにリクエストを転送します。 Traffic Server がクライアントからの no-cache ディレクティブを無視するように設定することもできます。この場合、クライアントからのリクエストの no-cache ヘッダーを無視して、キャッシュからオブジェクトを配信します。

  1. records.configproxy.config.http.cache.ignore_client_no_cache を編集してください。

    CONFIG proxy.config.http.cache.ignore_client_no_cache INT 1
    
  2. 設定変更を適用するために traffic_ctl config reload を実行してください。

オリジンサーバーディレクティブ

デフォルトでは Traffic Server は次のレスポンスヘッダーを持つオブジェクトをキャッシュしません。

サーバーの no-cache ヘッダーを無視する Traffic Server の設定

デフォルトでは Traffic Server は Cache-Control: no-cache ディレクティブを正確に守ります。 no-cache ヘッダーが付いているオリジンサーバーからのレスポンスはキャッシュに保存されません。また、以前キャッシュされたオブジェクトのコピーは削除されます。 no-cache ヘッダーを無視するように Traffic Server を設定した場合、 Traffic Server は no-store ヘッダーも無視します。 no-cache ディレクティブを守るデフォルトの振る舞いはほとんどの場合に適切です。

サーバーの no-cache ヘッダーを無視するように Traffic Server を設定するには :

  1. records.config の :ts:cv:`proxy.config.http.cache.ignore_server_no_cache ` を編集してください。

    CONFIG proxy.config.http.cache.ignore_server_no_cache INT 1
    
  2. 設定変更を適用するために traffic_ctl config reload を実行してください。

WWW-Authenticate ヘッダーを無視する Traffic Server の設定

デフォルトでは Traffic Server は WWW-Authenticate レスポンスヘッダーを含むオブジェクトをキャッシュしません。 WWW-Authenticate ヘッダーはクライアントがオリジンサーバーへのチャレンジレスポンス認証の際に使う認証パラメーターを含んでいます。

オリジンサーバーの WWW-Authenticate ヘッダーを無視するように Traffic Server を設定した場合、 WWW-Authenticate ヘッダーを持つ全てのオブジェクトは次のリクエストの為にキャッシュに保存されます。しかし、 WWW-Authenticate ヘッダーを持つオブジェクトをキャッシュしないデフォルトの振る舞いは多くの場合に適切です。 WWW-Authenticate ヘッダーを無視するように Traffic Server を設定するのは HTTP 1.1 に精通してる場合にだけにしてください。

WWW-Authenticate ヘッダーを無視するように Traffic Server を設定するには :

  1. records.config の :ts:cv:`proxy.config.http.cache.ignore_authentication ` を編集してください。

    CONFIG proxy.config.http.cache.ignore_authentication INT 1
    
  2. 設定変更を適用するために traffic_ctl config reload を実行してください。

設定ディレクティブ

クライアントやオリジンサーバーのディレクティブに加えて、 Traffic Server は設定オプションやファイルを通じて設定したディレクティブにも反応します。

次のように Traffic Server を設定することができます。

HTTP オブジェクトキャッシュの無効化

デフォルトでは Traffic Server は cache.config ファイルに設定した never-cache アクションルール を除く全ての HTTP オブジェクトをキャッシュします。後述するように HTTP オブジェクトがオリジンサーバーから直接配信され、決してキャッシュされな いように HTTP オブジェクトのキャッシュを無効化することができます。

HTTP オブジェクトキャッシュを手動で無効化するには :

  1. Set proxy.config.http.cache.http to 0 in records.config.

    CONFIG proxy.config.http.cache.http INT 0
    
  2. 設定変更を適用するために traffic_ctl config reload を実行してください。

動的コンテンツのキャッシュ

.asp で終わったり、クエスチョンマーク (?)、セミコロン (;) や cgi を含んでいたりする URL は動的であると考えられます。デフォルトでは Traffic Server は動的コンテンツをキャッシュします。コンテンツが本当に動的である場合にだけ推奨されますが、適切な Cache-Control ヘッダーによって伝えることができないとき、動的だと思われるコンテンツを無視するようにシステムを設定することができます。

動的コンテンツに配慮した Traffic Server の振る舞いを設定するには :

  1. records.configproxy.config.http.cache.cache_urls_that_look_dynamic を編集してください。キャッシュを無効にするには 0 に設定し、明示的にキャッシュを許可するには 1 に設定してください。

    CONFIG proxy.config.http.cache.cache_urls_that_look_dynamic INT 0
    
  2. 設定変更を適用するために traffic_ctl config reload を実行してください。

クッキーオブジェクトのキャッシュ

By default, Traffic Server caches objects served in response to requests that contain cookies. This is true for all types of objects including text. Traffic Server does not cache cookied text content because object headers are stored along with the object, and personalized cookie header values could be saved with the object. With non-text objects, it is unlikely that personalized headers are delivered or used.

次のように Traffic Server を設定し直すことができます。

  • クッキーを含む全てのコンテンツをキャッシュしない
  • クッキーを含む画像のみキャッシュする
  • タイプを考慮せずクッキーを含む全てのコンテンツをキャッシュする

クッキーを含むコンテンツをどのようにキャッシュするか Traffic Server を設定するには :

  1. records.configproxy.config.http.cache.cache_responses_to_cookies を編集してください。
  2. 設定変更を適用するために traffic_ctl config reload を実行してください。

オブジェクトの強制キャッシュ

Cache-Control レスポンスヘッダーを無視して、特定の期間に特定の URL (動的 URL も含む) をキャッシュすることを Traffic Server に強制することができます。

ドキュメントを強制的にキャッシュするには :

  1. Traffic Server にキャッシュに留めさせたい URL 毎に cache.config にルールを追加してください。

    url_regex=^https?://(www.)?apache.org/dev/ ttl-in-cache=6h
    
  2. 設定変更を適用するために traffic_ctl config reload を実行してください。

HTTP オブジェクトの代替のキャッシュ

いくつかの同一の URL へ複数のオブジェクトを回答するオリジンサーバーもあります。これらのオブジェクトのコンテンツはサーバーが異なる言語ごとにコンテンツを配信したり、異なるブラウザ毎にプレゼンテーションスタイルを用意していたり、異なるドキュメントフォーマット (HTML, XML) を提供しているか等により、多岐にわたります。同一オブジェクトの異なるバージョンは 代替 と呼ばれ、Vary レスポンスヘッダーに基づいて Traffic Server にキャッシュされます。 Traffic Server がキャッシュする代替を判別する特別な Content-Type をリクエストやレスポンスヘッダに追加することができます。キャッシュする代替バージョンの数を制限することもできます。

Traffic Server がキャッシュする代替の設定

Traffic Server が代替をキャッシュするように設定するには :

  1. records.config の次の変数を編集してください :
  2. 設定変更を適用するために traffic_ctl config reload を実行してください。

注釈

上の変数に Cookie を切り替えるためのヘッダーフィールドとして指定した場合、 proxy.config.http.cache.cache_responses_to_cookies が適切にセットされていることを確認してください。

オブジェクトの代替数の制限

Traffic Server がオブジェクト毎にキャッシュする代替数を制限することができます。(デフォルトは 3 です)

重要

全ての代替は同一の URL を持つため、代替の数が多いと Traffic Server のキャッシュパフォーマンスに影響を与えるかもしれません。Traffic Server はインデックス中の URL をとても高速に検索しますが、キャッシュストアの中に使用可能な代替があるかはシーケンシャルにスキャンしなければなりません。

オブジェクトの代替数の制限を変更するには :

  1. records.configproxy.config.cache.limits.http.max_alts を編集してください

    CONFIG proxy.config.cache.limits.http.max_alts INT 5
    
  2. 設定変更を適用するために traffic_ctl config reload を実行してください。

輻輳制御

輻輳制御 オプションはオリジンサーバーが混雑しているときに Traffic Server が HTTP リクエストを転送することを止めることを可能にします。 Traffic Server はその後、混雑してるオリジンサーバーに後でリトライするメッセージをクライアントに送ります。

このオプションを有効にするには :

  1. records.configproxy.config.http.congestion_control.enabled1 にセットしてください

    CONFIG proxy.config.http.congestion_control.enabled INT 1
    
  2. ルールを作成して congestion.config ファイルに次のように記述してください :

    • Traffic Server がどのオリジンサーバーの輻輳を監視するか
    • Traffic Server がサーバーが輻輳したかの基準にするタイムアウト
    • サーバーが輻輳したときに Traffic Server がクライアントへ送信するページ
    • Traffic Server が IP アドレス毎に追跡するか、ホストネーム毎に追跡するかどうか
  3. 設定変更を適用するために traffic_ctl config reload を実行してください。

トランザクションバッファリング制御

デフォルトでは I/O オペレーションは Traffic Server やネットワークやキャッシュが実行できる限り速くフルスピードで実行されます。これはクライアント側のコネクションが遅い場合に、大きなオブジェクトにとって問題になる可能性があります。このような場合、クライアントに送られるのを待っている間、コンテンツはメモリにバッファーされます。これはクライアントのコネクションが早く、オリジンサーバーのコネクションが遅い場合に POST リクエストでも発生し得ます。とても大きなオブジェクトが使われているとこれは Traffic Server のメモリ使用量がとても大きくなる原因になり得ます。 very large

This problem can be ameliorated by controlling the amount of buffer space used by a transaction. A high water and low water mark are set in terms of bytes used by the transaction. If the buffer space in use exceeds the high water mark, the connection is throttled to prevent additional external data from arriving. Internal operations continue to proceed at full speed until the buffer space in use drops below the low water mark and external data I/O is re-enabled.

主に Traffic Server のメモリ使用量を制限することを意図していますが、これはまた大雑把なレートリミッターも提供します。これはバッファーリミットの設定と、外部やトランスフォームの影響により、クライアント側のコネクションを減速させることによります。これはオリジンサーバーへのコネクションがクライアント側のコネクションスピードにより大まかに制限されることをもたします。

Traffic Server はネットワーク I/O をラージチャンク(32K など) で行います。よって、トランザクションバッファリングコントロールの粒度は同じような値に制限されています。

バッファーサイズの計算はトランザクションの全ての要素を含んでいます。これは transform plugins に紐づけられているどんなバッファーも含みます。

トランザクションバッファーコントロールは設定変数を使ってグローバルに有効化することもできます。また TSHttpTxnConfigIntSet() を使用してプラグインの中で有効化することもできます。

変数 TSHttpTxnConfigIntSet() キー
バッファーの有効化 proxy.config.http.flow_control.enabled TS_CONFIG_HTTP_FLOW_CONTROL_ENABLED
high water の設定 proxy.config.http.flow_control.high_water TS_CONFIG_HTTP_FLOW_CONTROL_HIGH_WATER
low water の設定 proxy.config.http.flow_control.low_water TS_CONFIG_HTTP_FLOW_CONTROL_LOW_WATER

low water マークは high water マークと常に同じか少ないことに注意してください。一方だけを設定すると、もう一方は同じ値に設定されます。

TSHttpTxnConfigIntSet() を使う場合、TS_HTTP_READ_RESPONSE_HDR_HOOK より後ろで呼んではいけません。

オリジンサーバーへのリクエストの削減(Thundering Herd 問題を避ける)

オブジェクトがキャッシュから配信されない場合、リクエストはオリジンサーバーにプロキシーされます。ポピュラーなオブジェクトにとって、これはオリジンサーバーへ多くの同じ様なリクエストを送り、可能性としては計り知れない程の関連したリソースを使うかもしれません。 Traffic Server にはこのシナリオを避けられるいくつかの機能があります。

Read While Writer

Traffic Server がオリジンからオブジェクトをフェッチしに行くとき、そしてレスポンスを受け取るとき、受け取ったオブジェクトの background_fill_completed_threshold % が満たされた部分的キャッシュオブジェクトを配信することがどんな数のクライアントにも許されています。

他の HTTP プロキシーはオリジンサーバーからデータを受け取ったらすぐにクライアントがレスポンスを読み始めることを許可していますが、ATS は完全なレスポンスヘッダーを受け取るまでクライアントが読み始めることを許可しません。これは ATS がキャッシュリフレッシュとコールドキャッシュを区別しておらず、そのためレスポンスがキャッシュ可能なものか知る方法がないことの副作用です。

オリジンサーバーからのキャッシュ出来ないレスポンスは一般的は異なるクライアントリクエストに対してユニークなコンテンツなので、 ATS はオブジェクトをキャッシュ出来ると判断するまで read-while-writer を有効にはしません。

ATS で read-while-writer 機能を有効にするには records.config で以下の設定を行う必要があります

CONFIG proxy.config.cache.enable_read_while_writer INT 1
CONFIG proxy.config.http.background_fill_active_timeout INT 0
CONFIG proxy.config.http.background_fill_completed_threshold FLOAT 0.000000
CONFIG proxy.config.cache.max_doc_size INT 0

次の理由により、4つ全ての設定が必要です。

  • バックグラウンドフィル機能 (proxy.config.http.background_fill_active_timeoutproxy.config.http.background_fill_completed_threshold の両方) は全てのあり得るリクエストでキックされることが許可されているべきです。 writer (ATSがオリジンサーバーへ接続するトリガーとなったオブジェクトリクエストの最初のクライアントセッション) が出て行った場合にこれは重要となります。他のクライアントセッションが writer を引継ぐ必要があります。

    そのようにするには、バックグラウンドフィルタイムアウトを設定し、境界点をゼロにするべきです。これは彼らがタイムアウトせずに、キックインすることを常に許可されることを保証します。

  • proxy.config.cache.max_doc_size は無制限(0)に設定されているべきです。オブジェクトサイズは (訳注: 事前には) 分からないからです。この制限を超えると配信されているオブジェクトのコネクションの切断を引き起こすかもしれません。

一度これらが有効化されると、Squid の Collapesd Forwarding にとても近いが異なるものものができます。

上記の設定に加えて、 proxy.config.cache.read_while_writer.max_retriesproxy.config.cache.read_while_writer_retry.delay の設定はオブジェクトの最初のフラグメントのダウンロードが完了するまで TS が read-while-writer をトリガーすることを試みる回数を制御できます

CONFIG proxy.config.cache.read_while_writer.max_retries INT 10

CONFIG proxy.config.cache.read_while_writer_retry.delay INT 50

Fuzzy Revalidation

注釈

These options are deprecated as of v6.2.0.

Traffic Server はキャッシュが新鮮でなくなる前に、オブジェクトの再確認を試みるように設定することもできす。records.config に次の設定があります

CONFIG proxy.config.http.cache.fuzz.time INT 240
CONFIG proxy.config.http.cache.fuzz.min_time INT 0
CONFIG proxy.config.http.cache.fuzz.probability FLOAT 0.005

オブジェクトが新鮮でないとセットされるよりも proxy.config.http.cache.fuzz.time (上の例では 240 秒) だけ経過時間が短いオブジェクトへの全てのリクエストには、オリジンへの再確認リクエストを引き起こすわずかな可能性 ( proxy.config.http.cache.fuzz.probability == 0.5% ) があります。

注釈

再確認が発生すると、リクエストされたオブジェクトはもはやキャッシュから配信することはできなくなります。そのオブジェクトへの以降のリクエストはオリジンサーバーにプロキシーされるでしょう。

秒間 2,3 リクエスト数しかないオブジェクトでは、これらの設定によりキャッシュされたオブジェクトが新鮮でなくなる前に再確認される確率は非常に低くなるでしょう。ですが、この機能はこれらの速度ではたいていは必要ではないでしょう。というのは新鮮でなくなるオブジェクトに対してオリジンサーバーにヒットする接続数は 1 か小さい数である確率が高いからです。

一旦リクエストの集中が発生すると、同じ fuzz.probability がオブジェクトが新鮮でなくなる前に再確認される可能性がより高くなることを引き起こします。これはより高い負荷の際に複数のクライアントが同時にオリジンサーバーへの接続を発生させることを妨げます。再確認に曖昧さ (fuzziness) が用いられなければそういう状況が発生していたことでしょう。

これらの設定は remap ルールとプラグインによってオーバーライド可能ですので、必要ならリクエスト毎に調整することが出来ます。

最後に proxy.config.http.cache.fuzz.min_time は小さい TTL と大きい TTL で再確認の確率を評価する時間が異なることを許容します。TTL の小さなオブジェクトは fuzz.min_time 付近で “再確認のサイコロを転がす” ことを始めます。一方、大きな TTL のオブジェクトは fuzz.time 付近で始めるでしょう。

対数のような関数が再確認査定を始める時間を決定します。(その値は``fuzz.min_time`` と fuzz.time の間でしょう) 期限切れに近いオブジェクトでは、期間の始まりはより可能性が高くなります。デフォルトではこの設定は有効化されていません。しかし、TTL の小さなオブジェクトがある場合、いつでも有効化するべきです。このオプションは設定を上書きする前に起きることに注意してください。よって、プラグインや remap.config 設定で同様なものを実現することができます。

これらの設定オプションは Squid の refresh_stale_hit 設定オプションに似ています。

Open Read リトライタイムアウト

オープンリードリトライ設定は与えられたオブジェクトに対してオリジンサーバーへの並列リクエストの数を減らすことを試みています。あるオブジェクトがオリジンサーバーからフェッチされている間、次のリクエストはオブジェクトがキャッシュから配信できるかどうかを確認する前に proxy.config.http.cache.open_read_retry_time ミリ秒待ちます。オブジェクトが依然としてフェッチされている場合、次のリクエストは proxy.config.http.cache.max_open_read_retries 回リトライします。すると、次のリクエストはオリジンサーバーへのコネクションを自分自身で確立する前に合計で (max_open_read_retries x open_read_retry_time) ミリ秒待ちます。例えばそれぞれ 510 にセットされた場合、このリクエストが許可されるまでコネクションは前回のリクエストがオリジンからレスポンスが帰ってくる間 50ms 待ちます。

重要

これらの設定はオブジェクトがキャッシュ不可能な場合、適切ではありません。これらの場合、オブジェクトへのリクエストは実際には直列になります。次のリクエストはオリジンにプロキシーされる前に少なくとも open_read_retry_time ミリ秒待たされるでしょう。

この設定は大きな (転送に (max_open_read_retries x open_read_retry_time) ミリ秒以上かかる) キャッシュ可能なオブジェクトの Read While Writer と共に使うように設定することが望ましいです。 read-while-writer 設定を有効化しないと、初回のフェッチが行われている間、次のリクエストが最大限遅れるだけではなく、結果としてオリジンサーバーへの不要なリクエストを発生させます。

ATS はリクエスト毎や remap ルールに設定することをサポートしているので、これはより簡単に適切に設定することができます。

設定 (とそのデフォルト値) は

CONFIG proxy.config.http.cache.max_open_read_retries INT -1
CONFIG proxy.config.http.cache.open_read_retry_time INT 10

デフォルトはこの機能が無効化されていて、全てのコネクションはオリジンに人為的な遅延無しに行くことを許可されていることを意味します。有効化した場合、open_read_retry_time タイムアウト毎に max_open_read_retries 回試すでしょう。

Open Write 失敗時のアクション

オープンリードリトライ設定に加えて TS は新しい設定 proxy.config.http.cache.open_write_fail_action をサポートします。これは複数の同時リクエストが同じオブジェクトを求めてオリジンにヒットすることをより一層減らします。それは1つのリクエストを除く全てのリクエストに対して、 hit-stale の場合には新鮮でないコピーを返すかキャッシュミスの場合にはエラーを返すことで実現します。