
Ich habe eine größtenteils statische Site, die auf Ruby on Rails läuft und den Varnish-Reverse-Proxy-Cache verwendet, um Zugriffe auf das Rails-Backend zu reduzieren.
Das Problem besteht darin, dass sich ein Benutzer bei der Site anmelden kann und wir dabei ESI (Edge Side Includes) verwenden, um benutzerspezifische Teile der Seite anzuzeigen.
Die Verwendung von ESI bedeutet, dass wir die Gzip-Komprimierung auf dem Rails-Backend deaktivieren müssen (mit Nginx+Passenger), da Varnish sonst die vom Backend zurückgegebenen Daten nicht analysieren kann, um die ESI-Verarbeitung auszuführen.
Meine Frage ist: Überwiegen die Vorteile der Verwendung eines Reverse-Proxy-Cache die Vorteile des GZIP-Komprimierens aller Ihrer Inhalte? Oder sollte ich versuchen, ESI vollständig loszuwerden und das Beste aus beiden Welten zu haben?
Antwort1
Sie können das Beste aus beiden Welten herausholen, wenn Sie die Dinge wie folgt arrangieren:
Benutzer -> nginx -> Varnish -> Rails
Schalten Sie die GZIP-Komprimierung von Nginx zum Benutzer ein. Das ist das langsamste und auch das teuerste Segment. Ich gehe davon aus, dass Ihre Nginx-, Varnish- und Rails-Instanzen lokal zueinander sind. Ihre lokale Bandbreite sollte mehr als ausreichend sein. Außerdem macht es nicht viel Sinn, GZIP nur zum Dekomprimieren zu verwenden, um das ESI zusammenzustellen.
Antwort2
Wenn die Bandbreite kein Problem darstellt und die Ladezeiten ohne Gzip akzeptabel sind, sollten Sie Gzip auf jeden Fall ausgeschaltet lassen.
Gzipping beansprucht viele CPU-Ressourcen. Wenn Ihnen also die CPU wichtiger ist als die Bandbreite, wenn die Site schnell genug geladen wird und wenn ESI eine große Hilfe für Sie ist, dann hat das Reverse-Proxy-Cache-System definitiv mehr Vorteile als das Gzipping von HTTP-Antworten.
In anderen Situationen, in denen die Bandbreite entscheidend ist, kann gzip wichtiger sein, aber das scheint hier nicht der Fall zu sein.
Schließlich kann Gzipping von einigen Reverse-Proxys durchgeführt werden. Dies ist eine großartige Möglichkeit, da Reverse-Proxys im Allgemeinen nicht viel CPU verbrauchen (wenn sie sich auf einem separaten Server befinden). Dies spart dem Backend viele CPU-Zyklen und spart auch Bandbreite, aber im Moment und wenn ich mich richtig erinnere, unterstützt Varnish kein Gzipping.