Ich bin kürzlich auf einen http-Web-Accelerator namens Varnish gestoßen. Nach dem, was ich gelesen habe, beschleunigt Varnish die Bereitstellung einer Website, indem jeder Prozess der HTTP-Kommunikation mit dem HTTP-Server mithilfe einer Reverse-Proxy-Konfiguration optimiert wird.
Meine Frage ist, dass, wenn Sie eine Website haben, deren Caching-Mechanismus bis auf statische HTML-Dateien konfiguriert ist, wie viel mehr von Varnish hat das dann? Verringert ein Reverse Proxy die Arbeit, die vom HTTP-Server ausgeführt wird, um die Anforderung zu verarbeiten? Wenn Sie alles umfassend serverseitig zwischengespeichert haben (HTTP-Header, Etags, Expires-Header, Datenbank-Caching, Fragment- und Page-Caching), was wird ein HTTP-Accelerator dann noch tun, um dies zu verbessern?
Zunächst sollten wir zwischen zwei verschiedenen Arten von Caching unterscheiden, die in einem normalen Web-System ablaufen: HTTP-Caching und serverseitiges Caching .
HTTP-Caching wird durch HTTP-Header gesteuert, insbesondere wenn Sie ETag und die verschiedenen Ablaufmechanismen (einschließlich Expires und verschiedene Aspekte von Cache-Control ) angeben. Dies alles ist in RFC 2616 (HTTP), Abschnitt 13 behandelt und erlaubt HTTP < em> caches , um eine Antwort auf eine HTTP-Anforderung von einem Client zurückzugeben, ohne zum Ursprungsserver zurückkehren zu müssen. Tatsächlich ermöglicht der HTTP-Caching-Mechanismus, dass ein anderer Computer zwischen Client und Server in bestimmten Fällen so fungiert, als wäre er der Server. Das ist tatsächlich was Lack tut, wie wir in einer Minute sehen werden; Eine andere häufige Anwendung, mit der viele Leute vertraut sind, ist, wenn ISPs in ihrem Netzwerk einen HTTP-Cache bereitstellen, der im Allgemeinen schneller auf ihre Abonnenten antworten kann (und so die wahrgenommene Leistung verbessert) als die Ursprungsserver außerhalb ihres Netzwerks.
Server-seitiges Caching umfasst Datenbank-Caching und Fragment- und Seiten-Caching, bei denen es sich wirklich nur um Möglichkeiten des Webservers handelt, eine kostspielige Operation (z. B. eine Datenbankabfrage oder ein Rendering) zu vermeiden Stück einer Vorlage), indem Sie es einmal tun und dann das Ergebnis für eine Weile in einem Cache behalten.
Ich sagte früher, dass Lack ein HTTP-Cache ist, was bedeutet, dass es sofort effizienter sein kann als ein Webserver, der sogar eine statische Datei bereitstellt. Überlegen Sie, was ein Webserver tun muss:
Accept-Encoding ) einer Datei Content-Length , Content-Type und die Header Expires und Last-Modified enthalten, die beim HTTP-Caching verwendet werden) ETag und Vary , beide wichtige Teile des HTTP-Caching) und allgemeine Header-Felder ( RFC 2616 Abschnitt 4.5 ) benötigt Im Vergleich dazu ist Lack stromaufwärts von all dem, also muss er nur:
Wenn es keinen Eintrag gibt, muss Lack etwas mehr Arbeit machen:
Insbesondere weil die HTTP-Header und der Entity-Body (die gesamte Response) durch Lackierung zwischengespeichert werden können, hat sie weniger Arbeit, wenn sie aus ihrem Cache heraus bedient werden kann. Wenn Sie beginnen, die Antwort dynamisch in Ihrem Server zu generieren, kann der Unterschied noch ausgeprägter werden: Sagen Sie, dass Sie eine Seite haben, die 5 Sekunden zum Generieren benötigt, aber für alle, die auf Ihre Website treffen, sollte Firnis in der Lage sein, diese zu liefern die meisten Millisekunden aus dem Cache (zuzüglich der Zeit, die benötigt wird, um die Antwort über das Netzwerk an den HTTP-Client zu erhalten), und hat einen ordentlichen Mechanismus (das Kulanzzeitraum ), damit es weiterhin ausgeführt werden kann, während er den Backend-Server einmal anspricht, um die zwischengespeicherte Version der Seite zu aktualisieren.
Natürlich können Sie serverseitiges Caching einführen, um die Geschwindigkeit zu verbessern, mit der Ihr Webserver eine Anfrage verarbeiten kann. Wenn Sie jedoch eine Antwort haben, die Sie in Lack zwischenspeichern können, ist dies im Allgemeinen schneller. (Es gibt verschiedene Dinge, die schwer in Lack zu cachen sind, besonders wenn Sie Cookies verwenden oder Seiten haben, die sich ändern, je nachdem welcher Benutzer sie betrachtet. Während es möglich ist, in diesen Fällen weiterhin Lack zu verwenden, außer Sie brauchen wirklich unglaublich Geschwindigkeit, so weit ich weiß, beginnen die meisten Leute, diese Fälle mit serverseitigem Caching und anderen Techniken zu optimieren, bevor sie Lack aufschlagen.)
(Beachten Sie, dass Lack auch Kopfzeilen und tatsächlich Daten, die in den Cache ein- und ausgehen, bearbeiten kann, was die Dinge kompliziert macht. Aber die Hauptpunkte stehen immer noch, und sogar während der Bearbeitung kann der Lack unglaublich schnell sein.) p>
Tags und Links http caching http-caching varnish