ATS が動的サービス スループットを向上させるためにキャッシュ戦略を実装する方法

まず、ポリシー調整直後のトラフィック グラフを見てみましょう。

# ユーザー エクスペリエンスを向上させるには、トラフィックを増やします。キャッシュの増幅率を高めると同時に、お客様から問題が報告されないように、キャッシュに重点を置き、大きなファイルと小さなファイルを分離し、小さなファイルでは動的コンテンツと静的コンテンツを分離しました。保存できるのは保存され、動的コンテンツのみが常に保存されていました。まだ開始していません。以前の戦略によれば、動的コンテンツは 1 対 1 の入口と出口で直接プロキシされます。しかし、一部のビューローは停止しません。一定の増幅率に到達することを主張し、割引がない場合は、動的コンテンツでナイフを使用しましょう。

問題を解決する前に、まず分析を行い、保存できる動的コンテンツと ATS キャッシュ戦略について多くのテストを行いました。その結果、多くのメリットが得られました。 ATS の現在のキャッシュ戦略は HTTP プロトコルに完全に準拠しており、最も保守的なキャッシュ方法を採用しています。つまり、明確なライフ サイクル キャッシュ ヘッダーを持つ情報のみが保存され、動的、Cookie、承認、キャッシュなしは保存されません。 ats 内の対応する設定パラメータは書き込まれません。品質を確保するため、Cookie と認証を使用して動的コンテンツを直接スキップします。その理由は、リスクが大きすぎるためです。残りのカテゴリを試すことができます:

1. 明確なライフ サイクル ヘッダーを持つ動的 URL 画像およびその他のコンテンツ; (Web サイトのヘッダー情報は信頼できると想定しています)

2. 明確なヘッダーのライフサイクル ヘッダーを持たない静的 URL 画像および動的 URL 画像 (情報がないもの、または最終変更ヘッダーのみのものを含む)写真やその他の情報。

最初のカテゴリについては、扱いが簡単です。ats には対応するパラメータがあるので、それを開くだけです:

proxy.config.http.cache.cache_urls_that_look_dynamic INT 1

For最初のカテゴリ カテゴリ 2 は、扱うべき技術的な問題です。まず、オンラインのヘッダー情報に必要な条件は次のとおりです。

proxy.config.http.cache.required_headersINT 2

Onlyカテゴリ 2 は制限によってのみ含めることができるため、0 に設定することが最初に必要です。設定した後、通常のサービスを確保するにはどうすればよいでしょうか。たとえば、検証コードの設定時にはヘッダー情報がありません。保守的で、通常のサービスを提供するのが我々の戦略であることは間違いありませんが、それを放っておくと必ずトラブルが発生します。分析後、ats は最大キャッシュ時間と最小キャッシュ時間を使用して、ヘッダー情報のないコンテンツのキャッシュ時間を確保します。2 つの時間パラメータは次のとおりです:

proxy.config.http.cache.heuristic_min_lifetime INT 3600

proxy.config.http.cache.heuristic_max_lifetime INT 864000

最終変更ヘッダーのみの情報については、エージング係数を通じて計算されます。エージング係数パラメータは次のとおりです:

proxy.config. http.cache.heuristic_lm_factor-v 0.1

そこで、コンテンツが到着した後に保存するというアイデアを思いつきましたが、各スピットの前に、ATS が IMS ヘッダー情報をオリジンに送信できるようにします。このヘッダー情報はAskだけなので、変更があるかどうかをサイトに問い合わせる場合、どのくらいのトラフィックが占有されないでしょうか? 変更がなければ、TCP_REFRESH_HITがユーザーに吐き出されます。ソースは返されますが、コンテンツはまだ残っています。キャッシュから吐き出されます。変更がある場合、TCP_REFRESH_MISS がユーザーに吐き出されます。ユーザーは最新のコンテンツも取得します。これにより、吐き出しフローの一部が事実上増加します。

しかし、パラメータを設定するにはどうすればよいでしょうか?上記のパラメータをすべて 0 に設定すれば理論的には目標を達成できると突然思いつき、一度保存した後、2 回目からソースに IMS ヘッダーを要求し始めたところ、すぐにテストが見つかりました。テスト用の環境です。予想通りでした。同様に興奮したところで、すぐにオンラインで戦略を更新し、トラフィック グラフ ツールで 1 時間監視しました。全体的な原点復帰は減りましたが、何か奇妙なことも起こりました。 tsar を見て、特定の瞬間の原点復帰が依然として同じであることを確認しました。ほとんど嘔吐しているようで、traffic_logstats -s で分析したところ、ERR_CLIENT_ABORT が大量にあることがわかりました。これは本当にひどいです。このログは、接続後、データを受信する前にクライアントが積極的に接続を切断しました。それが少ない場合は正常です。それが多い場合は、問題になります。はい、テスト用に最大保存期間の 1M イメージを見つけました。パージしました。このエラー ログを作成するために、最初に接続をカールし、すぐに切断しました。2 回目にアクセスしたとき、TCP_HIT であることがわかりました。ローカル イメージをダウンロードして、通常どおり開きました。なんてことだ、ATS は継続的に動作することが判明しました。この問題に対処するときは、キャッシュにダウンロードしてください。これらのドメイン名の品質が低いため、リターン トラフィックが非常に高くなることがあります。Google で情報を探し続けたところ、この記事を見つけました。パラメータ:

proxy .config.http.background_fill_completed_thresholdFLOAT 0.5

デフォルトは 0 に設定されています。このパラメータは、クライアントが突然切断され、ダウンロードが一定の割合に達するとダウンロードが続行されることを意味します。それ以外の場合は切断されます。多すぎるので、0.5に設定してテストし、すぐにアップデートしたところ、トラフィックが安定し、スループットも向上しました。

ようやく、小さな成功です。オンラインパラメータはそれほど安定していません。今後のビジネス状況に応じてテストを調整する必要がありますが、それも楽しみの一部です。

すべての調整はバランスです。現在の調整: 1. ディスク読み取りおよび書き込み IO の増加、2. CPU 負荷の増加。

以上がATS が動的サービス スループットを向上させるためにキャッシュ戦略を実装する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。