私はScalingRailsのスクリーンキャストに追いついてきました。高度なHTTPキャッシング（VarnishやSquidなどのリバースプロキシキャッシュを使用）をカバーするエピソード11では、Railsアプリケーション内のページ、アクション、フラグメントキャッシングの可能性をすでに使い果たした後でのみ、リバースプロキシキャッシュの使用を検討することをお勧めします。 （memcachedなども同様ですが、この質問には関係ありません）。
私が完全に理解できないのは、HTTPリバースプロキシキャッシュを使用すると、すでにページキャッシュを使用しているアプリケーションのパフォーマンスがどのように向上するかということです。問題を単純化するために、ここで単一のホストについて話していると仮定しましょう。
これは、両方の手法がどのように機能するかについての私の理解です（おそらく私は間違っています）：
ページキャッシングでは、Railsプロセスが最初にヒットし、その後、そのリクエストのキャッシュが有効である限り、後続のリクエストのためにWebサーバーによって直接提供される静的HTMLファイルを生成します。キャッシュの有効期限が切れている場合は、Railsが再度ヒットされ、静的ファイルが再生成され、更新されたコンテンツが次のリクエストに対応できるようになります。
HTTPリバースプロキシキャッシュを使用すると、プロキシがコンテンツが古くなっているかどうかを判断する必要がある場合に、Railsプロセスがヒットします。
ETagこれは、などのさまざまなHTTPヘッダーを使用して行われますLast-Modified。コンテンツが新しい場合、RailsはHTTP 304 Not Modifiedでプロキシに応答し、プロキシはキャッシュされたコンテンツをブラウザに提供します。さらに良いのは、独自のHTTP304で応答することです。 。コンテンツが古くなっている場合、Railsは更新されたコンテンツをプロキシに提供します。プロキシはコンテンツをキャッシュしてからブラウザに提供します。
私の理解が正しければ、ページのキャッシュによってRailsプロセスへのヒットが少なくなるのではないでしょうか。コンテンツが古くなっているかどうかを判断するために行ったり来たりすることはすべてありません。つまり、リバースプロキシキャッシングよりもパフォーマンスが優れています。なぜ両方の手法を組み合わせて使用するのでしょうか。