共有プロキシキャッシュがクローラーの役に立つとき
共有フォワードプロキシキャッシュでスループットが上がると期待する前に、繰り返されるリソース、鮮度、クローラーの実際の取得を評価してください。
ブラウザ上で動く複数のワーカーが、同じサイトの異なるページを開くとします。それらのページは同じスタイルシート、ロゴ、スクリプトバンドルを参照しています。共有フォワードキャッシュは、応答を再利用できる場合に、最初の取得を後続のワーカーにも有効にできます。
ここでワークロードを変えます。各ワーカーは HTML 文書を 1 つだけダウンロードし、リンクされたリソースを決して読み込みません。共通のスタイルシートはマークアップに残っていますが、どのワーカーも要求しません。プロキシのキャッシュヒット率には何も寄与しません。
クローラーが実際に行うリクエストから始める
ページを描画するブラウザと、そのソースを取得する HTTP クライアントでは、作られるリクエスト集合が異なります。キャッシュ設計を選ぶ前に、その集合を調べてください。
| ワークロード | 共有再利用の可能性 |
|---|---|
| ワーカーが同じ公開アセットを繰り返し取得する | 鮮度とキャッシュキーの規則が許す場合に有効 |
| すべてのリクエストが固有の URL または応答バリアントを持つ | 再利用できる重なりがほとんどない |
| 再利用の前に応答の再検証が必要 | 応答バイトは節約できるが、上流への往復は依然として必要 |
| ワーカーが自分のローカルキャッシュで要求を満たしている | その要求は共有プロキシに届かないことがある |
URL が等しいだけでは不十分です。応答の鮮度ポリシーと Vary で指定されたフィールドが表現を区別します。非公開、保存不可、認証付きの内容には該当する共有キャッシュの規則が必要です。ヒット数を上げるためだけに 1 つの公開結果へ押し込むべきではありません。
通常の HTTPS CONNECT 通信では、フォワードプロキシは暗号化されたトンネルを運び、内部にキャッシュできる HTTP オブジェクトはありません。TLS 検査を行う配備では信頼と処理の挙動が異なります。オブジェクトキャッシュが使えるかを評価するときは、実際のモードを含めてください。
キャッシュヒットは上流への取得を避けられますが、ミスは中継者の作業コストを依然として払います。想定するワークロードについて、完了した有効バイト、上流トラフィック、遅延を比較してください。スレッド数は並行性を表すもので、それらのスレッドがどれだけ再利用可能な内容を共有するかは表しません。