私は、Ruby on Rails 上で実行されているほとんど静的なサイトを持っています。このサイトでは、Rails バックエンドへのヒットを節約するために Varnish リバース プロキシ キャッシュを使用しています。
問題は、ユーザーがサイトにログインでき、ログインすると、ESI (エッジサイドインクルード) を使用してページのユーザー固有の部分が表示されることです。
ESI を使用するには、Rails バックエンドで Gzip 圧縮を無効にする必要があります (Nginx + passenger を使用)。そうしないと、varnish は ESI 処理を実行するためにバックエンドから返されたデータを解析できません。
私の質問は、リバース プロキシ キャッシュを使用する利点は、すべてのコンテンツを gzip 圧縮する利点を上回るかどうかです。それとも、ESI を完全に削除して、両方の長所を活かすようにするべきでしょうか。
答え1
次のように配置すれば、両方の長所を活かすことができます。
ユーザー -> nginx -> Varnish -> Rails
nginx からユーザーへの gzip 圧縮をオンにします。これは最も遅く、最もコストがかかるセグメントです。nginx、Varnish、および Rails インスタンスは互いにローカルであると想定しています。ローカル帯域幅は十分すぎるはずです。また、ESI を組み立てるために解凍するためだけに gzip 圧縮するのはあまり意味がありません。
答え2
帯域幅に問題がなく、gzip なしでも読み込み時間が許容できる場合は、gzip を必ずオフにしてください。
gzip 圧縮は CPU リソースを大量に消費します。そのため、帯域幅よりも CPU を重視し、サイトの読み込みが十分速く、ESI が非常に役立つ場合は、リバース プロキシ キャッシュ システムの方が、http 応答を gzip 圧縮するよりも間違いなくメリットがあります。
帯域幅が重要な他の状況では、gzip がより重要になる可能性がありますが、ここではそうではないようです。
最後に、gzip 圧縮は一部のリバース プロキシで実行できます。リバース プロキシは一般に CPU をあまり使用しないため (別のサーバー上にある場合)、これは大きな可能性です。これにより、バックエンドの CPU サイクルが大幅に節約され、帯域幅も節約されますが、現時点では、私の記憶が正しければ、Varnish は gzip 圧縮をサポートしていません。