我有一個在 Ruby on Rails 上運行的大部分靜態站點，該站點使用 Varnish 反向代理快取來保存對 Rails 後端的點擊。
問題是使用者可以登入網站，當他們登入時，我們使用 ESI（邊緣包含）來向使用者顯示頁面的特定部分。
使用ESI意味著我們必須在Rails後端（使用Nginx+passenger）停用Gzip壓縮，否則varnish無法解析從後端返回的資料以運行ESI處理。
我的問題是，使用反向代理快取的好處是否超過對所有內容進行 gzip 壓縮的好處？或者我應該嘗試完全擺脫 ESI 並兩全其美？
答案1
如果你這樣安排，你就可以兩全其美：
使用者 -> nginx -> Varnish -> Rails
開啟從 nginx 到使用者的 gzip 壓縮。這是最慢的部分，也是成本最高的部分。我假設您的 nginx、Varnish 和 Rails 實例彼此是本地的。您的本地頻寬應該綽綽有餘。此外，僅透過 gzip 解壓縮來組裝 ESI 並沒有多大意義。
答案2
如果頻寬不是問題，並且載入時間在沒有 gzip 的情況下是可以接受的，那麼您絕對應該關閉 gzip。
Gzip 壓縮會佔用大量 CPU 資源。因此，如果您更關心 CPU 而不是頻寬，如果網站加載速度足夠快，並且 ESI 對您有很大幫助，那麼反向代理快取系統肯定比 gzip 壓縮 http 回應有更多好處。
在其他情況下，頻寬至關重要，gzip 可能更重要，但這裡的情況似乎並非如此。
最後，gzip 壓縮可以透過一些反向代理來完成。這是一個很大的可能性，因為反向代理通常不會使用太多 CPU（如果它們位於單獨的伺服器上）。這為後端節省了大量的CPU週期，也節省了頻寬，但目前，如果我沒記錯的話，Varnish不支援gzipping。