Auf der Symfony2 Doku Seite zum HTTP Cache wird sehr gut und ausführlich beschrieben, wie man aus einer Applikation noch mehr Speed durch Caching heraus holt. Dieser Geschwindigkeitszuwachs kann durch den eingebauten gateway cache oder durch einen externen Server/Dienst wie Varnish, der als Reverse Proxy fungiert, erreicht werden.
Die Funktionsweise des Cachings und der Edge Side Includes sind sicherlich einen extra Artikel wert. Da ich aber selbst bei Wikipedia nichts auf Deutsch dazu gefunden habe, habe ich kurzer Hand den englischen Artikel auf Deutsch übersetzt . 🙂
Varnish als Lastverteiler
Mir geht es aber um den Einsatz eines Varnish Servers als Lastverteiler. Nate Haug hat dazu einen sehr ausführlichen Artikel auf der Seite www.lullabot.com veröffentlicht. Er beschreibt die Konfiguration eines Varnish Servers (natürlich ausfallsicher) als Load Balancer.
Dieser versteht es nämlich den Verkehr nach bestimmten Anforderungen auf verschiedene, hinter ihm liegende, Webserver zu verteilen. Die Lastverteilung kann man sehr gut einstellen, so dass man auch einen Server, der mit anderen Aufgaben beschäftigt ist, als niedrig priorisierten zusätzlichen Knoten in den Webserver-Verbund mit aufnehmen kann. Es folgt die Übersetzung des o.g. Artikels.
Konfiguration von Varnish
Varnish hat normalerweise drei Dateien für die Konfiguration. Das Boot-Script, die systemweite Konfiguration und die VCL-Datei, die den Großteil der Arbeit übernimmt.
Das erste Script, welches gestartet wird, liegt – wie die meisten Startup-Scripte – unter /etc/init.d/varnish. Diese Datei benötigt kaum Änderungen, kann aber zum Verständnis beitragen und helfen, die weiteren Konfigurationsdateien zu finden, da das Startup-Script verantwortlich für deren Aufruf ist.
Die zweite Datei findet man normalerweise unter /etc/sysconfig/varnish (auf CentOS and RedHat Maschinen) oder unter/etc/default/varnish (auf Ubuntu).
Diese Datei definiert die globale Konfiguration für Varnish, z. B. auf welchem Port er laufen und wo der Cache gespeichert werden soll. Es gibt fünf verschiedene Möglichkeiten, das gleiche zu schreiben, wichtig ist nur, dass man die Cache Ablage von dem Default-Wert „file“, der den Cache auf die Festplatte auslagert, auf die Angabe „malloc“ umstellt, da dies die Auslagerung in den Arbeitsspeicher gewährt. Nur letzteres macht wirklich Sinn. Wenn Sie nicht genug Arbeitsspeicher haben, (sagen wir ein paar Gigabyte) solllten Sie sich überlegen diesen aufzustocken.
Hier ist eine Beispiel-Konfiguration, die Nate Haug bei einem sehr populären Webauftritt benutzt, mit einer großen Anzahl Bilder und vielen Seiten, die gecached werden. Hier die Bespieldatei /etc/sysconfig/varnish :
DAEMON_OPTS="-a :80,:443 \ -T localhost:6082 \ -f /etc/varnish/default.vcl \ -u varnish -g varnish \ -S /etc/varnish/secret \ -p thread_pool_add_delay=2 \ -p thread_pools=<Number of CPU cores> \ -p thread_pool_min=<800 / Number of CPU cores> \ -p thread_pool_max=4000 \ -p session_linger=50 \ -p sess_workspace=262144 \ -s malloc,3G"
Die letzte Zeile ist die Wichtigste, die gesetzt werden muss. In diesem Fall reservieren wir 3 Gigabyte Arbeitsspeicher für Varnish. Beachten Sie auch den Pfad, der anzeigt, welche VCL Datei genutzt werden soll. Es ist das Beste bei dem default Dateipfad der eingesetzten Distribution zu bleiben. Bitte beachten Sie die Zeilen in denen <Number of CPU cores>, steht und setzen Sie die Werte Ihres Servers ein. Um Informationen über Ihr System zu erhalten können Sie in der Kommandozeile einfach grep processor /proc/cpuinfo, eingeben.
VCL Konfiguration
Die VCL Konfigurationsdatei ist das Herzstück um Varnish zu konfigurieren und dort werden alle wichtigen Änderungen vorgenommen. Es ist wichtig zu wissen, dass Varnish eine große Anzahl an Default Einstellungen enthält, die sich automatisch an die benutzerdefinierten Regeln anpassen.
Solange man keine speziellen Kommandos wie, „pipe“, „pass“, oder „lookup“ benutzt, laufen die default Werte. Varnish wird mit einer komplett auskommentierten default.vcl Datei ausgeliefert, die als Referenz dient.
Wir arbeiten uns durch alle Sektionen. Hier ist eine Datei, die Nate Haug in seinem Unternehmen (Lullabot) zur Zeit einsetzt sowie eine Kopie der Varnish default Datei.
Lullabot’s default.vcl Datei für mehrere Web Server
defaults.vcl (von Varnish 2.1.3)
Jetzt wird`s richtig interessant – die VCL Datei!
Gesunheitschecks und Direktoren („directors“)
Ein neueres Feature von Varnish (Version 2.x und höher) war das Hinzufügen von Direktoren, um den Datenverkehr auf eine beliebige Anzahl von Webservern aufzuteilen. Diese Direktoren haben Zugriff auf jeden Webserver, um zu überprüfen, ob der Server noch läuft und in welchem Zustand er sich befindet. Wenn Varnish eine Web-Anfrage erhält, die noch nicht gecached ist, wird die Anfrage nur an einen „gesunden“ (d.h. einen niedrig ausgelasteten) Server weitergereicht.
Der Varnish Server wird normalerweise so konfiguriert, dass er auf HTTP und HTTPS Verkehr reagiert. Also benötigen wir die Liste von Webservern in „zweifacher Ausfertigung“, soll heißen einmal den Port 80 für den normalen Verkehr sowie den Port 443 für SSL-verschlüsselte Verbindungen. Wenn Sie den Apache anders konfiguriert haben, müssen Sie die Ports dementsprechend anpassen.
# Define the list of backends (web servers).
# Port 80 Backend Servers
backend web1 { .host = "192.10.0.1"; .probe = { .url = "/status.php"; .interval = 5s; .timeout = 1s; .window = 5;.threshold = 3; }}
backend web2 { .host = "192.10.0.2"; .probe = { .url = "/status.php"; .interval = 5s; .timeout = 1s; .window = 5;.threshold = 3; }}
# Port 443 Backend Servers for SSL
backend web1_ssl { .host = "192.10.0.1"; .port = "443"; .probe = { .url = "/status.php"; .interval = 5s; .timeout = 1 s; .window = 5;.threshold = 3; }}
backend web2_ssl { .host = "192.10.0.2"; .port = "443"; .probe = { .url = "/status.php"; .interval = 5s; .timeout = 1 s; .window = 5;.threshold = 3; }}
# Define the director that determines how to distribute incoming requests.
director default_director round-robin {
{ .backend = web1; }
{ .backend = web2; }
}director ssl_director round-robin {
{ .backend = web1_ssl; }
{ .backend = web2_ssl; }
}
# Respond to incoming requests.
sub vcl_recv {
# Set the director to cycle between web servers.
if (server.port == 443) {
set req.backend = ssl_director;
}
else {
set req.backend = default_director;
}
}Der letzte Teil der Konfiguration ist in der vcl_recv Sub-Routine. Er definiert, welches Server-Set benutzt wird – basierend auf dem Port, auf dem Varnish den Verkehr erhalten hat.
Es ist eine gute Idee den verantwortlichen „health check“ (also ein kleines Programm für den Feedback des Gesundheitszustands) auf jedem Web-Server zu installieren, um sicher zu gehen, das der Server bereit ist Daten zu liefern. Nate benutzt eine lokale Datei, direkt im root Verzeichnis des Webservers, mit dem Namen „status.php“ um den Gesundheitszustand des Servers zu testen. Diese Datei testet viele Dinge. Unter anderem die folgenden:
- testen, ob Drupal geladen wurde
- die Verbindung zu der Master Datenbank
- die Verbindung zu der Slave Datenbank (wenn vorhanden)
- die Verbindung zu Memcache (wenn es genutzt wird)
- es wird überprüft, ob der Webserver Schreibrechte auf das /files Verzeichnis hat
Wenn eine dieser Überprüfungen fehl schlägt, wirft das Script einen 500er Fehler und Varnish nimmt den Server aus der Rotation. Die status.php Datei ist natürlich auch sehr hilfreich, um einen Webserver offline zu nehmen. Wenn man die Datei einfach umbenennt, nimmt Varnish den Server aus der Rotation, während der Server selbst noch weiter läuft. Dies ist zum Beispiel nützlich um Wartungsarbeiten durchzuführen. Dieses Verfahren hat sich auch für das Durchführen von Upgrades oder dem Installieren neuer Software durchgesetzt.
Die status.php ist zwar relativ allgemein gehalten, sollte aber an den jeweiligen Anwendungszweck angepasst werden. Wenn Sie also weitere Dienste für den Betrieb Ihres Server benötigen, nehmen Sie diese auch mit in das Script auf, so dass Varnish keine Daten von einem nicht funktionierenden Server entgegen nimmt.
Caching, auch wenn der Apache Webserver nicht mehr erreichbar ist
Selbst wenn eine Umgebung komplett redundant ausgelegt ist, ist es möglich, dass die Webseite, aus verschiedensten Gründen, nicht erreichbar ist. Ein Programmierfehler, ein Datenbank Fehler, ein Verbindungsfehler oder einfach sehr viel Datenverkehr. In solchen Situationen (der häufigste Fall ist, das der Apache Server überlastet ist und Anfragen ablehnt) kann Varnish einem den Hintern retten. Varnish arbeitet dann mit einer „Schonfrist“. Der Apache Web Server gibt jeder Antwort, die er ausliefert, ein Auslaufdatum mit. Das bedeutet, dass Varnish den alten Inhalt verwirft und eine neue Antwort vom Webserver anfordert, wenn das Auslaufdatum erreicht ist. Wenn der Server aus o.g. Gründen nicht erreichbar ist, ist es unmöglich eine neue Antwort zu erhalten. „Grace“ (Gnade) ist eine Einstellung, die es Varnish erlaubt, Seiten weiterhin auszuliefern, obwohl diese eigentlich schon veraltet sind, aber der Webserver nicht erreichbar ist. Varnish liefert diese veralteten Daten solange aus, bis der Webserver wieder verfügbar ist.
Um „Grace“ zu aktivieren müssen nur die folgenden Einstellungen in den Bereichenvcl_recv undvcl_fetchvor genommen werden:
# Respond to incoming requests.
sub vcl_recv
{
# Allow the backend to serve up stale content if it is responding slowly.
set req.grace = 6h;
}
# Code determining what to do when serving items from the Apache servers.
sub vcl_fetch
{
# Allow items to be stale if needed.
set beresp.grace = 6h;
}Beide Einstellungen können das Gleiche bedeuten,
aber das Setzen der Option in der vcl_fetch Einstellung muss länger sein, als das in vcl_recv. Man könnte die vcl_fetch „grace“ Einstellung als die maximale Zeit, die Varnish ein Objekt im Cache halten darf, betrachten. Die Einstellung in der vcl_recv definiert, wann Varnish ein veraltetes Objekt benutzen soll, insofern eines vorhanden ist.
Auch wenn die Vorteile von „grace“ beeindruckend sind, so sollte man immer daran denken, dass die Seite bereits im Cache sein muss, damit dieser Mechanismus funktioniert. Dies kann ein Problem werden, wenn man mit authentifizierten Benutzern zu tun hat, die nur schwer cachbare Dateien ausgeliefert bekommen. Wenn Sie ungecachte Seiten an authentifizierte Nutzer ausliefern und all Ihre Webserver versagen den Dienst, sind das Letzte, was die Nutzer sehen sollen, Fehlermeldungen. Wäre es nicht besser, wenn Varnish einen Fallback zu anonymen Seiten hätte, die bereits gecached sind, bis der Webserver wieder online ist? Glücklicherweise gibt es diesen Fallback und so etwas einzurichten ist sehr einfach. Ergänzen Sie einfach den folgenden Code in der vcl_recv Subroutine:
# Respond to incoming requests.
sub vcl_recv
{
# ...code from above.
# Use anonymous, cached pages if all backends are down.
if (!req.backend.healthy)
{
unset req.http.Cookie;
}
}Varnish setzt eine Eigenschaft "req.backend.health" , wenn einer der Webserver erreichbar ist. Wenn alle Server unerreichbar sind, wird dieses Flag auf „false“ gesetzt. Varnish entfernt den Cookie eines eingeloggten Users von dem eingehenden Request und versucht eine anonyme Version der Seite zu bekommen. Sobald ein Server wieder erreichbar ist, wird Varnish den Cookie wieder mitgeben, so dass der Nutzer – mit etwas Glück, eingeloggt bleibt.
Wie man Varnish dazu bringt, bestimmte Antworten nicht zu cachen
Bei vielen Webseiten ist es nötig, bestimmte Seiten, bzw. Seitenbereiche niemals zu cachen. Ein gutes Beispiel dafür ist sicherlich die Anzeige der eigenen Kontodaten bei einem eingeloggten Nutzer. In diesen Szenarien kann man Varnish einfach das „pass“ Statement mitgeben. Die Daten werden dann von Varnish unter keinen Umständen gecached. Hier ein typisches Beispiel für Drupal:
# Do not cache these paths.
if (req.url ~ "^/status\.php$" ||
req.url ~ "^/update\.php$" ||
req.url ~ "^/ooyala/ping$" ||
req.url ~ "^/admin/build/features" ||
req.url ~ "^/info/.*$" ||
req.url ~ "^/flag/.*$" ||
req.url ~ "^.*/ajax/.*$" ||
req.url ~ "^.*/ahah/.*$") {
return (pass);
}Varnish wird natürlich immer noch den Verkehr zwischen der äußeren Welt und dem Webserver behandeln, aber das „pass“ Kommando sichert, dass die Anfragen immer an den Webserver weiter geleitet werden.
In einigen Situationen ist es jedoch unerlässlich, dass Varnish eine direkte Verbindung zwischen der äußeren Welt und dem Webserver herstellt. Warum?
Varnish beantwortet alle Anfragen mit einer bestimmten „content-length“ („Dateigröße“). Diese Information erlaubt dem Browser, dem Nutzer den Fortschritt anzuzeigen. Aber einige Dateien haben keine vorhersagbare Länge. Streamingdaten (Audio/Video) aber auch zur Laufzeit generierte Dateien, wie zum Beispiel PDF-Dateien, haben eine unbekannte Größe und Varnish kann keine „content legth“ ausgeben. Damit Varnish, auch mit solchen Situationen umgehen kann, muss man ihn mit dem Kommando „pipe“ füttern. Dann werden die Anfragen direkt an den Webserver durchgeleitet, d.h. Varnish funktioniert eher als eine Art Gateway.
Damit Varnish weiterhin in solchen Situationen funktioniert, muss er mit dem Kommando „pipe“ gefüttert werden.
# Pipe these paths directly to Apache for streaming.
if (req.url ~ "^/admin/content/backup_migrate/export") {
return (pipe);
}Varnish ist auch ein gute Möglichkeit, um den Zugriff auf bestimmte URLs zu verhindern. Da die VCL Datei so flexibel nutzbar ist, kann man solche Pfade leicht verstecken. Am Beginn unserer VCL-Datei haben wir eine Zeile, die eine Access Control List in Form von IP-Adressen enthält. Diese Adressen werden als intern betrachtet. Ein gutes Beispiel wäre z.B. Drupal´s cron.php Datei. Diese Datei darf nur von den lokalen Webserver angestoßen werden, da sie zeitintensive Tasks, wie das Aufbauen des Suchindex, ausführt. Da die lokalen Webserver alle den Adressbereich 192.10.X.X haben, wird ihnen der Zugriff gewährt; alle anderen erhalten eine „Zugriff verweigert“ Nachricht.
Am Anfang der default.vcl Datei werden die lokalen Zugriffe gewährt:
# Define the internal network subnet.
# These are used below to allow internal access to certain files while not
# allowing access from the public internet.
acl internal
{
"192.10.0.0"/24;
}Und dann in dem vcl_recvBereich:
# Respond to incoming requests.
sub vcl_recv
{
# ...code from above.# Do not allow outside access to cron.php or install.php.
if (req.url ~ "^/(cron|install)\.php$" && !client.ip ~ internal)
{
# Have Varnish throw the error directly.
error 404 "Page not found.";
# Use a custom error page that you've defined in Drupal at the path "404".
# set req.url = "/404";
}
}Den Cache von Varnish optimieren
Als erstes nehmen wir eine immer wieder kursierende, aber misslungene Konfiguration, auseinander. Wenn es darum geht, wie der gecachte Inhalt an User mit Cookies ausgeliefert wird, empfehlen viele Quellen die folgende Konfiguration:
# Routine used to determine the cache key if storing/retrieving a cached page.
sub vcl_hash
{
# Do NOT use this unless you want to store per-user caches.
if (req.http.Cookie)
{
set req.hash += req.http.Cookie;
}
}Normalerweise ist dies keine sinnvolle Empfehlung, solange man nicht eine gecachte Seite mehrfach an einen User ausliefert. Diese Einstellung erkennt den einmaligen Key, z.B. von Drupal, und verhindert, dass gecachte Inhalte zwischen Usern ausgetauscht werden. Diese Einstellung ist aber eine Resourcenverschwendung, da Drupal explizit den Cache-Control Header für angemeldete User auf „unter keinen Umständen cachen“ setzt:
Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
In anderen Worten, vermeiden Sie diese Einstellung, es sei denn, Sie haben wirklich einen Grund userspezifische Seiten zu cachen. In den meisten Situationen wird diese Einstellung einen Overhead erzeugen, ohne dass etwas gespeichert wird. Im Worst-Case-Szenario wird Ihr Cache mit Einträgen von jedem authentifizierten Nutzer gefüllt und die wirklich wichtigen anonymen Caches, die für tausende Nutzer genutzt werden können, werden hinaus gedrängt.
In den meisten Fällen ist es am sinnvollsten einen Cache für alle User vorzuhalten. Jeder Inhalt, der nicht an alle User ausgeliefert werden kann, kann direkt an Apache weiter gereicht werden. Da Drupal einen Cookie nutzt um authentifizierte Nutzer zu unterscheiden, ist es das Einfachste danach Ausschau zu halten und diese Anfragen dann nicht zu cachen. Dieses Cookie wird allerdings auch an Bilder, CSS und JavaScript-Dateien (eigentlich alle Mediendateien) gehangen.
Die HTML Seite kann für eingeloggte Nutzer durchaus anders aussehen aber es gibt keinen Grund die o.g. Dateien nicht zu cachen. Die einfachste Möglichkeit dies zu erreichen, ist die Cookies für diese Dateitypen generell zu verwerfen.
# Respond to incoming requests.
sub vcl_recv
{
# ...code from above.
# Always cache the following file types for all users.
if (req.url ~ "(?i)\.(png|gif|jpeg|jpg|ico|swf|css|js|html|htm)(\?[a-z0-9]+)?$")
{
unset req.http.Cookie;
}
}So weit so gut. Wenn man die Cookies für statische Dateien entfernt, werden diese für alle Nutzer gecached. Dies funktioniert für Standardinstallationen von Drupal, aber unglücklicherweise gibt es noch weitere Möglichkeiten Cookies zu setzen. Die häufigsten Problembereiter sind statische Tracking Scripts (wie Google Analytics) und Werbeserver. Ad-Scripts haben eine schreckliche Art Cookies per JavaScript zu setzen. Meistens werden Varnish und Drupal von diesen Cookies nicht behelligt. Da aber jeder Cookie, der Varnish vom Browser übergeben wird, Varnish dazu bringt den Request direkt an Apache weiter zu reichen, müssen wir auf diese Cookies gesondert achten.
Es gibt viele Ansätze sich diesem Problem zu nähren, und die meisten Administratoren starten mit einer Blacklist von Cookies, die ausgefiltert werden müssen, damit nur die gewünschten übrig bleiben. Das könnte dann wie folgt aussehen:
// Remove has_js and Google Analytics __* cookies. set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(__[a-z]+|has_js)=[^;]*", "");
Dieser Ansatz wird normalerweise für einen kurzen Zeitraum funktionieren, aber sobald ein Ad-Script oder ein neues Stück JavaScript einen Cookie hinzufügt (wie das Kommentar Modul, oder das Flag Modul oder eines der vielen anderen Module), wird Varnish wieder gezwungen das Cachen der Seite zu unterlassen. Man muss dann den Übeltäter suchen und manuell zur Blacklist hinzufügen.
Es wäre doch sinnvoller eine Art Whitelist zu führen, in der alle Cookies die nicht aufgeführt sind, automatisch verworfen werden. Die Logik ist umfangreicher aber sicherlich auch eine dauerhafte Lösung:
# Respond to incoming requests.
sub vcl_recv
{
# ...code from above.
# Remove all cookies that Drupal doesn't need to know about. ANY remaining
# cookie will cause the request to pass-through to Apache. For the most part
# we always set the NO_CACHE cookie after any POST request, disabling the
# Varnish cache temporarily. The session cookie allows all authenticated users
# to pass through as long as they're logged in.
if (req.http.Cookie)
{
set req.http.Cookie = ";" req.http.Cookie;
set req.http.Cookie = regsuball(req.http.Cookie, "; +", ";");
set req.http.Cookie = regsuball(req.http.Cookie, ";(SESS[a-z0-9]+|NO_CACHE)=", "; \1=");
set req.http.Cookie = regsuball(req.http.Cookie, ";[^ ][^;]*", "");
set req.http.Cookie = regsuball(req.http.Cookie, "^[; ]+|[; ]+$", "");if (req.http.Cookie == "")
{
# If there are no remaining cookies, remove the cookie header. If there
# aren't any cookie headers, Varnish's default behavior will be to cache
# the page.
unset req.http.Cookie;
}
else
{
# If there are any cookies left (a session or NO_CACHE cookie), do not
# cache the page. Pass it on to Apache directly.
return (pass);
}
}
}Sobald Sie Cookies gezähmt haben, kommt auch schon der nächste Feind des Cachings um die Ecke, der „Accept-Encoding“ Header, der von den Browsern mit gesendet wird. Jeder Browser sendet Informationen über seine Caching Fähigkeiten zum Server. Alle modernen Browser unterstützen zum Beispiel die „gzip“ Kompression aber jeder informiert den Server auf eine andere Weise. Zum Beispiel so:
Firefox, IE: gzip, deflate Chrome: gzip,deflate,sdch Opera: deflate, gzip, x-gzip, identity, *;q=0
Zusätzlich zu den Headern, die vom Browser gesendet werden muss Varnish auch noch auf die Header vom Webserver achten, die normalerweise Zeilen wie die folgende enthalten:
Vary: Accept-Encoding
Das bedeutet, dass Varnish für jede Version von „Accept-Encoding“ eine eigene Version, für jeden verbundenen Browser vorhalten muss. Das bedeutet, dass Varnish für jeden Browser und, im schlimmsten Fall sogar für verschiedene Versionen des selben Browsers, eigene Cache Dateien anlegt. Dies ist nicht nur eine Verschwendung von Speicherplatz sondern macht das Cachen auch recht ineffizient, da ja eigentlich jeder Browser „gzip“ versteht, es nur unterschiedlich mitteilt. Um diesen Umstand zu vermeiden fügen wir das folgende Segment in die vcl_recv-Datei ein:
# Handle compression correctly. Different browsers send different
# "Accept-Encoding" headers, even though they mostly all support the same
# compression mechanisms. By consolidating these compression headers into
# a consistent format, we can reduce the size of the cache and get more hits.
# @see: http:// varnish.projects.linpro.no/wiki/FAQ/Compression
if (req.http.Accept-Encoding)
{
if (req.http.Accept-Encoding ~ "gzip")
{
# If the browser supports it, we'll use gzip.
set req.http.Accept-Encoding = "gzip";
}
else if (req.http.Accept-Encoding ~ "deflate")
{
# Next, try deflate if it is supported.
set req.http.Accept-Encoding = "deflate";
}
else
{
# Unknown algorithm. Remove it and send unencoded.
unset req.http.Accept-Encoding;
}
}Fazit
Varnish ist ein erstaunliches und extrem effizientes Tool um Webseiten auszuliefern. Neben der tollen Eigenschaft, Ihre Seite schneller zu machen, erweitert Varnish Ihr System zusätzlich um Redundanz, da es als eine Art Backup fungiert und auch wenn der Webserver nicht erreichbar ist. Um Varnish zu diesem effektiven Backup- und Caching-System zu machen, muss er die eingehenden Header des Browsers säubern, überflüssige Cookies verwerfen und den „Accept-Encoding“ Header konsolidieren.
Nach so ausführlichen Erläuterungen kann man leicht von der Problematik überwältigt werden aber die gute Nachricht ist, die hier angebotenen Dateien können „out of the box“ für so ziemlich jede Drupal Seite verwendet werden und gleich ihre Arbeit aufnehmen. Für die meisten Seiten sind keine zusätzlichen Anpassungen notwendig und die Seiten, die noch etwas Feintuning benötigen, haben eine gute Grundlage. Varnish beantwortet, auf den Seiten von lullabot, ungefähr 85 % der Anfragen ohne den Webserver überhaupt anzufragen. Selbst in Hochlast-Zeiten mit hunderttausenden Anfragen pro Stunde, benötigt Varnish nur ca. 5 % der CPU auf einem durchschnittlichen 4-Kern-Server. Anstatt mehr Webserver zu kaufen und einzurichten, sollten Sie lieber ein oder mehrere Varnish Maschinen vor den Webservern einrichten. Dies kann eine unglaubliche Entlastung für die Webserver sein und gleichzeitig Ihre Webseite beschleunigen.
Wenn Sie die aktuelle default.vcl, die von lullabot eingesetzt wird, noch nicht herunter geladen haben, sollten Sie das jetzt tun. Mit den ausführlichen Erklärungen können Sie ihre eigene VCL Konfiguration starten. Happy Caching.
Hi Maik,
danke für den Artikel. Hat mir bei der Einrichtung super geholfen. Danke! 🙂