In letzter Zeit wurde viel darüber gesagt die Vorzüge von statischen Websites . In vielen Situationen ist jedoch ein dynamischer Ansatz notwendig. Ob ein Content-Management-System, ein Customer-Relationship-Tool oder ein Online-Shop - Endanwender können komplexe Sites schnell und konsistent pflegen. Und wenn sie richtig zusammengebaut sind, können sie mit statischen Standorten mit der Geschwindigkeit konkurrieren.
Jede Anwendung, die häufig Daten lesen und schreiben muss, verursacht eine merkliche Verzögerung
Welches System Sie auch verwenden, dynamische Seiten enthalten normalerweise ähnliche Elemente. Dies sind eine Form von Webserver, ein Backend und eine Anwendung, die in einer oder mehreren Programmiersprachen geschrieben sind. Diese Kombination von Komponenten bietet ein hohes Maß an Flexibilität, aber jeder trägt seinen eigenen Overhead bei und erhöht die Ladezeit, was alle modernen Websites vermeiden möchten. Dies gilt insbesondere für den Datenbankzugriff: Jede Anwendung, die häufig Daten lesen und schreiben muss, verursacht eine merkliche Verzögerung.
Hier hilft Caching und eine geeignete Caching-Strategie für Ihren Anwendungsfall. Das grundlegende Ziel des Caching besteht darin, unnötig häufige Aufrufe zwischen den Anwendungsdatenbankschichten zu verhindern und stattdessen vorgenerierte statische HTML-Seiten zu verwenden, die in einem Browser viel schneller gerendert werden können.
Der erste Cache, den jeder Web-Benutzer bemerkt hätte, ist der Cache in seinem Browser. Wie oft haben Entwickler Sie gebeten, eine "Force-Aktualisierung" durchzuführen, um Änderungen zu sehen? Browser-Caches sind einfach, aber ein guter Ausgangspunkt, um Caching-Konzepte zu erklären. Ein Browser speichert Darstellungen von Webseiten, die auf dem Computer eines Benutzers besucht wurden, und aktualisiert sie typischerweise einmal pro Sitzung, wenn Änderungen von der Site erkannt oder erzwungen werden.
Ein übliches Tool, das von Websitebesitzern und Administratoren verwendet wird, ist ein "Reverse-Proxy-Cache", der zwischen Seitenanforderungen eines Webbrowsers und der Webanwendung sitzt. Es fängt Anfragen ab und rendert Kopien von Seiten direkt aus dem Cache, was zu einer spürbaren Beschleunigung der Geschwindigkeit führt.
Es gibt mehrere wichtige Proxy-Cache-Optionen für die Selbstinstallation oder als "Software as a Service". (Wir ignorieren Cloud-Hosting-Anbieter, die normalerweise alles, was Sie benötigen, in einen eigenständigen Web-Stack verpacken.)
Beliebte Proxy-Cache-Optionen umfassen:
SaaS-Optionen für das Caching befinden sich im Allgemeinen in der Welt der Content Delivery Networks (CDNs), die anstelle eines Zwischenspeichers zwischen einem Benutzer und einem Webstapel Benutzergruppen mit zwischengespeicherten Inhalten bereitstellen, die geografisch am nächsten an ihnen liegen. Es ist ein subtiler Unterschied, aber für große Websites mit einem globalen Publikum kann dies einen entscheidenden Unterschied ausmachen.
Lack ist in allen Linux - Paketmanagern verfügbar, als Docker - Image und viele andere Optionen, lesen Sie die Projekt-Installationsseite für mehr Details.
Varnish speichert eine Standardkonfigurationsdatei entweder unter /usr/local/etc/varnish/default.vcl oder /etc/varnish/default.vcl , geschrieben in VCL (Varnish-Konfigurationssprache). Diese Konfigurationsdatei wird über einen C-Interpreter in ein kleines Programm kompiliert, um die Geschwindigkeit noch weiter zu steigern.
Je nachdem, wie Sie Varnish installiert haben, sieht die Konfigurationsdatei ungefähr so aus:
backend default {.host = "127.0.0.1";.port = "8000";}
Im einfachsten Fall definiert dies das Standard-Backend, das von Varnish verwendet wird, indem es den Host und den Port definiert, auf den es zuhören und Inhalte abfangen soll.
Eine praktische Funktion von Varnish ist es, in vordefinierten Intervallen zu überprüfen, ob ein Backend noch in Ordnung ist. Es heißt "Backend Polling" und wird konfiguriert, indem ein Probe-Abschnitt in die Backend-Deklaration eingefügt wird:
.probe = {.url = '/';.timeout = 34ms;.interval = 1s;.window = 10;.threshold = 8;}
Dies sind die Standardeinstellungen, die von Varnish bereitgestellt werden, und weisen darauf hin, dass ein bestimmtes .url in jedem Intervall aufgerufen wird und dass das Back- End immer noch als fehlerfrei gilt , wenn die URL innerhalb von mindestens . Einmal als "ungesund" betrachtet, wird Inhalt für einen vordefinierten Zeitraum aus dem Cache bereitgestellt.
Wir werden spezifische Änderungen an der Varnish-Konfiguration unter jeder Plattform-Option behandeln, jetzt wollen wir uns die allgemeinen Optionen ansehen.
Häfen
Zu Beginn muss der Port für Ihren Webserver vom Standardwert geändert werden. Zum Beispiel in der Apache Vhost Konfiguration den Port auf 81 oder 8080 ändern.
Starten Sie den Varnish-Daemon mit dem Befehl varnish oder mit einem Service-Wrapper. Der Daemon hat Flag-Optionen, die am häufigsten und nützlichsten sind:
Alles überprüfen funktioniert
Führen Sie den Befehl varnishstat aus oder besuchen Sie ihn isvarnishworking.com um zu überprüfen, ob Ihr Varnish-Server bereit ist und Anfragen zu hören.
Was nicht zu cachen
Es gibt bestimmte Teile einer Site, die wir nicht zwischenspeichern möchten, zum Beispiel die Administrationsseiten. Wir können sie ausschließen, indem wir in der Datei default.vcl eine Unterroutine vcl_recv erstellen, die eine if- Anweisung enthält, die definiert, was nicht zwischengespeichert werden soll:
sub vcl_recv {# URI of admin folderif (req.url ~ "^/url/"){return (pass);}return(lookup);}
Wenn Sie Varnish 4 verwenden, sind die Dinge etwas anders, einschließlich der Rückgabewerte. Die vcl_recv- Funktion gibt jetzt einen Hash- Wert statt einer Suche zurück.
sub vcl_recv {...return(hash);}
Hier legen wir auch Sites oder Subdomains fest, die Varnish ignorieren sollte, indem Sie der if- Anweisung req.http.host ~ 'example.com' hinzufügen.
Kekse
Standardmäßig speichert Varnish keinen Inhalt vom Backend, der Cookies setzt. Wenn der Client einen Cookie sendet, wird Varnish direkt zum Backend weitergeleitet.
Cookies werden häufig von Websites verwendet, um Benutzeraktivitäten zu verfolgen und benutzerspezifische Werte zu speichern. Im Allgemeinen sind diese Cookies nur für den clientseitigen Code von Interesse und für das Backend oder Varnish nicht von Interesse. Wir können Varnish mitteilen, Cookies zu ignorieren, außer in bestimmten Bereichen der Website:
if ( !( req.url ~ ^/admin/) ) {unset req.http.Cookie;}
Diese if- Anweisung ignoriert Cookies, es sei denn, wir befinden uns im Admin-Bereich der Website, wo die Cookie-Weitergabe von mehr Nutzen sein kann (es sei denn, Sie möchten die Site-Administratoren wirklich frustrieren).
Andere Ausnahmen
Bei einer Standardinstallation speichert Varnish auch keine passwortgeschützten Seiten, GET- und HEAD-Anfragen.
Wir werden uns nun zwei perfekte Anwendungsfälle für Varnish ansehen: Drupal und Magento. Beides sind hochdynamische Systeme, die es technisch nicht versierten Benutzern ermöglichen, eine Vielzahl komplexer Aufgaben zu übernehmen. Dies kann dazu führen, dass Datenbankabfrage-schwere Seitenladungen und belegte Seiten merklich langsam werden. Bei typischen Seiten, die mit diesen Systemen erstellt werden, wird eine Mischung aus Inhalten selten und häufig aktualisiert.
Drupal verfügt über Standard-Caching-Optionen, die ähnliche Funktionen wie Varnish ausführen, jedoch nicht die Flexibilität oder Geschwindigkeitserhöhung bieten, die für größere oder komplexere Sites erforderlich sind.
In echter Drupal Manier gibt es eine Modul zur Handhabung der Lackintegration um einige der oben beschriebenen manuellen Konfigurationen zu speichern.
Installieren Sie das Modul und stellen Sie sicher, dass Sie die Installationsanweisungen in der Readme-Datei des Moduls befolgen.
Stellen Sie sicher, dass für die Datei / etc / default / varn folgende Dämonoptionen festgelegt sind (und die Einrückung ist wichtig):
DAEMON_OPTS="-a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s file,/var/lib/varnish/$INSTANCE/varnish_storage.bin,128M"
Stellen Sie sicher, dass Apache und alle zugehörigen virtuellen Hosts Port 8080 und nicht 80 überwachen. Starten Sie beide Dienste neu, nachdem Sie diese Änderungen vorgenommen haben.
Möglicherweise müssen Sie auf der Modulkonfigurationsseite einen "Lackkontrollschlüssel" einstellen. Finden Sie mit dem Befehl cat / etc / varnish / secret heraus, was dieser Schlüssel ist, und fügen Sie ihn in die Einstellungsseite ein. Wählen Sie die richtige Varnish-Version, speichern Sie die Einstellungen und Sie sollten eine Reihe grüner Häkchen am Ende der Seite sehen.
Das Varnish-Modul interagiert mit den Standard-Drupal-Cache-Einstellungen. Stellen Sie daher sicher, dass Sie dies für Ihren Anwendungsfall aktiviert und konfiguriert haben.
Führen Sie varlstat von der Befehlszeile aus, starten Sie die Navigation als anonymer Benutzer, und Sie sollten sehen, dass sich die Statistiken in der Befehlsausgabe ändern.
Einer der Pfade, die wir in Drupal nicht zwischenspeichern möchten, sind die Admin-Seiten, die wir mit einer vcl_recv - Subroutine ausführen können :
sub vcl_recv {# URI of admin folderif (req.url ~ "^/admin/"){return (pass);}unset req.http.Cookie;return(lookup);}
Sie sollten nicht in Betracht ziehen, Benutzer-Seiten, Systemaktualisierungsseiten und andere Seiten, die von hochdynamischen Modulen wie Flags, die umfangreiche Funktionen von ajax verwenden, zu verwenden, nicht im Cache speichern. Tun Sie dies, indem Sie der if- Anweisung weitere req.url- Parameter hinzufügen.
Eine Standardinstallation von Magento wird mit einem internen Caching-System ausgeliefert, das statische Versionen von Site-Elementen in einem angegebenen Ordner speichert. Die Seite System -> Cache Management bietet einen Überblick über den aktuellen Cache-Status und ermöglicht das Löschen aller oder einzelner Komponenten-Caches. Auf dieser Seite können Sie aggregierte CSS- und JS-Dateien sowie automatisch generierte Bilddateien löschen.
Die kommende Version 2 von Magento wird standardmäßig das Varnish Caching unterstützen, aber für den Moment müssen wir Plugins von Drittanbietern verwenden, ich empfehle das Terpentin Modul . Stellen Sie sicher, dass Sie die Projekt Readme-Datei Wenn Sie einige zusätzliche Konfigurationsschritte notieren, kann das Ignorieren der Website Ihre Website beschädigen.
Das Terpentine-Modul ist in hohem Maße konfigurierbar und nimmt die notwendigen Änderungen an den vcl- Dateien und der Varnish-Konfiguration für Sie vor. Einige wichtige Optionen sind:
Das Turpentine-Modul ist mit dem Standard-Magento-Cache verknüpft, sodass das Löschen von Caches auf der Varnish-Cache-Seite die entsprechenden Varnish-Caches löscht.
Abgesehen von der Verwendung von Varnish mit einem der obigen dynamischen Systeme, gibt es hier noch eine Reihe anderer Tipps, die die Cache-Fähigkeit jeder Site unterstützen.
Wenn Sie denselben Inhalt in verschiedenen Kontexten bereitstellen, sollte dieselbe URL verwendet werden. Zum Beispiel mischen Sie nicht die Verwendung von article.html , article.htm und article , obwohl Ihr CMS es erlaubt. Dies führt zu drei verschiedenen im Cache gespeicherten Versionen desselben Inhalts.
Wie wir oben gesehen haben, sind Cookies schwer zu cachen und sind selten so notwendig wie wir denken. Versuchen Sie, ihre Verwendung und Anzahl auf dynamische Seiten zu beschränken.
Das Laden von Site-Assets kann einer der zeitaufwendigsten Teile einer Seite sein und es gibt einfache Tipps, um diese Last zu reduzieren:
Die Verwendung von CSS Image-Sprites für die Ikonographie anstelle von mehreren kleinen Dateien führt zu weniger Netzwerkverkehr.
Das lokale Hosting von CSS- und JavaScript-Bibliotheken bedeutet weniger Netzwerkverkehr und mehr Kontrolle über Caching-Strategien. Dies kann einen erhöhten Wartungsaufwand bedeuten, um diese Anlagen auf dem neuesten Stand zu halten. Speichern Sie diese Assets in konsistent benannten Ordnern, sodass Verweise auf sie ebenfalls konsistent sein können.
Ich hoffe, dass diese Einführung zur Beschleunigung Ihrer dynamischen Websites mit Caching nützlich war. Der Leistungsgewinn ist eine erste Phase der Konfiguration, des Experimentierens und der Feinabstimmung wert. In dieser Zeit der kurzen Aufmerksamkeitsspanne und Ungeduld macht jeder Geschwindigkeitsgewinn, den Sie aus Ihrem Setup herausholen können, den Unterschied für Ihre Benutzer und den Wettbewerb.