9

最近、Varnish という http Web アクセラレータに出会いました。私が読んだことによると、Varnish は、リバース プロキシ構成を使用して HTTP サーバーとの HTTP 通信のすべてのプロセスを最適化することにより、Web サイトの配信を高速化します。

私の質問は、キャッシュ メカニズムが静的な html ファイルに至るまで構成されている Web サイトがある場合、Varnish はこれにどの程度の影響を与えるでしょうか? リバース プロキシは、HTTP サーバーが要求を処理するために実行する作業を削減しますか? サーバー側にすべてが広範囲にキャッシュされている場合 (HTTP ヘッダー、Etags、Expires ヘッダー、データベース キャッシング、フラグメント、およびページ キャッシング)、HTTP アクセラレータはこれを改善するためにさらに何をしますか?

4

1 に答える 1

21

まず、通常の Web システムで実行される 2 つの異なるタイプのキャッシング、HTTP キャッシングとサーバー側キャッシングを区別する必要があります。

HTTPキャッシングは、特に指摘したように、HTTPヘッダーETagとさまざまな有効期限メカニズム（Expiresおよびのさまざまな側面を含むCache-Control）によって制御されます。これはすべてRFC 2616 (HTTP) のセクション 13でカバーされており、オリジン サーバーに戻ることなく、 HTTPキャッシュがクライアントからの HTTP 要求に対する応答を返すことができます。. 実際には、HTTP キャッシング メカニズムにより、クライアントとサーバーの間の別のマシンが、場合によってはサーバーであるかのように動作することができます。すぐにわかるように、これは実際にワニスが行っていることです。多くの人がよく知っているもう 1 つの一般的な使用法は、ISP がネットワーク内に HTTP キャッシュを提供する場合です。これは一般に、ネットワーク外のオリジン サーバーよりも加入者に高速に応答できます (したがって、知覚されるパフォーマンスが向上します)。

サーバー側キャッシングには、データベース キャッシング、フラグメントおよびページ キャッシングが含まれます。これらはすべて、Web サーバーがコストのかかる操作 (データベース クエリやテンプレートの特定の部分のレンダリングなど) を一度実行することで回避する方法にすぎません。結果をしばらくキャッシュに保持します。

前に、ワニスは HTTP キャッシュであると言いました。つまり、静的ファイルを提供する Web サーバーよりもすぐに効率的になります。Web サーバーが何をしなければならないかを考えてみましょう。

  1. HTTP リクエストを解析する
  2. URI (および などの関連する要求ヘッダーAccept-Encoding) をファイルにマップする
  3. ファイルに関する情報を取得して、応答で HTTP ヘッダーを作成します。これらはエンティティ ヘッダーとして知られています( RFC 2616 セクション 7.1。HTTP キャッシングで使用される、 およびContent-LengthヘッダーContent-Typeなどを含みます)。ExpiresLast-Modified
  4. 追加の応答ヘッダー( RFC 2616 セクション 6.2。これらには、 HTTP キャッシュの重要な部分である と が含まれます) とETag一般的なヘッダー フィールド( RFC 2616 セクション 4.5 ) が必要かどうかを判断します。Vary
  5. HTTP ステータス行とヘッダーをネットワークに書き出す
  6. ファイルの内容をネットワークに書き出す

比較すると、ワニスはこれらすべての上流にあるため、次のことだけを行う必要があります。

  1. HTTP リクエストを解析する
  2. 内部キャッシュ内のエントリに URI (および関連する要求ヘッダー) をマップする
  3. エントリがあるかどうかを確認します。存在する場合は、ネットワークに書き込みます。HTTP ヘッダーはキャッシュに保存されます

エントリがない場合、ワニスはもう少し作業を行う必要があります。

  1. その背後にある Web サーバーに接続し、最初のリストのすべての手順 1 ～ 6 を実行して応答を生成します。
  2. すべての HTTP ヘッダーを含めて、ネットワークへの応答を書き込みます
  3. レスポンスをキャッシュに保存する

特に、HTTP ヘッダーとエンティティ ボディ (応答全体) は varnish によってキャッシュできるため、キャッシュからサービスを提供できれば、実行する作業が少なくなります。サーバーで応答を動的に生成し始めると、違いがさらに顕著になる可能性があります。たとえば、生成に 5 秒かかるページがあるとしますが、サイトにアクセスするすべての人にとって同じであるとします。キャッシュからのほとんどのミリ秒 (さらに、ネットワークを介して HTTP クライアントへの応答を取得するのにかかる時間)、きちんとしたメカニズム (猶予期間) があるため、バックエンド サーバーに 1 回アクセスして更新している間も処理を続けることができます。ページのキャッシュされたバージョン。

もちろん、サーバー側のキャッシュを導入して、Web サーバーがリクエストを処理する速度を向上させることはできますが、応答がある場合は、ニスにキャッシュすることができます。(特に Cookie を使用している場合や、閲覧しているユーザーに応じて変化するページがある場合は、varnish にキャッシュするのが難しいさまざまなものがあります。これらの場合でも、本当に信じられないほどの必要がない限り、varnish を使用し続けることは可能ですが、私の知る限り、ほとんどの人はワニスを使用する前に、サーバー側のキャッシュやその他の手法を使用してこれらのケースの最適化を開始しています。)

(varnish はヘッダーを編集することもでき、実際にはキャッシュに出入りするデータも編集できることに注意してください。これは物事を複雑にします.

于 2012-04-01T19:02:20.143 に答える