Marco Gabriel

Varnish ist ein extrem schneller caching reverse Proxy, der einem normalen Webserver vorgeschaltet wird. In der Regel beantwortet Varnish dann die Anfragen der Benutzer, entscheidet, ob er aus seinem eigenen Cache liefern kann und den Webserver dahinter nicht mehr fragen muss. Da Varnish den Proxy im Speicher hält, bedient er Anfragen extrem schnell. Was er nicht selbst bedienen kann, z.B. weil die Seiten aktive Inhalte haben oder nicht gecached werden dürfen, gibt er an den dahinter liegenden Webserver weiter. Darüber hinaus überwacht er die Webserver und verteilt Anfragen an mehrere Webserver. Fällt einer der Webserver aus, leitet Varnish dort einfach keine Anfragen mehr hin. Benutzer bekommen davon überhaupt nichts mit. Varnish ist übrigens auch völlig anpassbar über eine eigene Konfigurationssprache. Damit lassen sich extrem tolle Dinge relativ einfach realisieren.

Ich kam irgendwann auf die Idee, auch normale, einzelne Webserver mit einem Varnish auszustatten, um die Auslieferung von Web Inhalten zu beschleunigen. Zunächst klang das für mich bei allen oben genannten Vorteilen wie eine Verbesserung. Zumal der Varnish auf dem gleichen Host lief und über eine iptables Regel eingebunden wurde, d.h. mein Varnish war jederzeit im Betrieb transparent ein- und abschaltbar. Nicht mal die Webserver Konfiguration musste ich ändern.

Als ich mir die Statistiken des Varnish ansah, war dort allerdings kaum ein positiver Effekt zu erkennen. Die Cache Hit Rate war oft unter 1%, so dass sich kein erkennbarer Gewinn daraus erzielen liess. Varnishhist zeigt ein ähnliches Ergebnis, aber etwas schöner als Varnishstat:

Ausgabe von varnishhist: Unter (1) sieht man die Hits, unter (2) die an den Webserver weitergeleiteten Requests. Von links nach rechts erhöht sich die Antwortzeit.

Der Grund dafür ist recht schnell ausgemacht. Sobald Cookies existieren, geht Varnish von einer Session aus und leitet einfach alle Anfragen an den Webserver weiter. Da heute die meisten Websites Content Management Systeme für alles einsetzen, läuft bereits beim ersten Besuch ein Cookie auf und eine Session startet. Damit ist Varnish außen vor.

Varnish handelt an dieser Stelle völlig korrekt, um die Stabilität der Webanwendungen vor die Performance zu stellen.

Bei kleinen Webservern, die verschiedene Websites ausliefern und alle nicht auf Varnish optimiert sind, ergibt der Einsatz von Varnish deshalb (leider) auch keinen Sinn. Man kann mittels der Scriptsprache Varnish beibringen, dass er trotzdem statische Dateien wie Bilder, CSS, etc. cached, der Aufwand lohnt sich aus meiner Erfahrung heraus trotzdem nicht.

Neulich hatte ich eine Unterhaltung darüber, wie man die Laufzeit eines Programms möglichst einfach misst. Im konkreten Fall wollten wir wissen, wie lange ein mysqldump benötigt hat. Dazu gibts unter Linux den Befehl time, den man dem zu messenden Programm einfach voranstellt.

time <Programm und Parameter>
[...Ausgabe des Programms...]

real    0m56.754s
user    0m0.784s
sys    0m4.004s

Der Wert hinter real zeigt an, wie lange das Programm gelaufen ist, im obigen Beispiel 0 Minuten, 56 Sekunden und 754 Millisekunden.

Für ein Zarafa Upgrade von 6.40 auf 7.1 musste ich eine MySQL Datenbank von einem alten auf einen neuen Server übernehmen. Da es sich um eine relativ große Datenbank handelte, testete ich den Vorgang vorab und alles funktionierte - inklusive dem Dump und dem Restore der Datenbank.

Beim eigentlichen Upgrade dann brach der Dump mit der folgenden Meldung ab:

mysqldump: Error 2020: Got packet bigger than ‘max_allowed_packet’

Das Problem ist, dass mysqldump nicht die gleichen Konfigurationsparameter wie der mysqld verwendet. In der /etc/mysql/my.cnf kommt ganz weit unten eine Sektion namens [mysqldump], in der man die max_allowed_packet Größe anpassen muss, wenn der Server ebenfalls größere Pakete zulässt. Passt man diese Größe nicht an, können Backups unbrauchbar sein weil sie mittendrin abbrechen.

Der Standardwert liegt bei 16M und sollte je nach Anwendung höher gesetzt werden. Bei Zarafa ist in der Regel 32M bis 64M völlig ausreichend, da die MAPI Objekte zwar größer sein können, die Attachments jedoch im Filesystem und nicht in der Datenbank liegen. Demnach muss die Datenbank meist weniger als 32M liefern.

Wenn man mysqldump von einem anderen Host aus startet (der keine my.cnf besitzt) oder die Koonfiguration nicht anpassen möchte, kann man auch als Parameter --max-allowed-packet=32M angeben. Damit wird der Eintrag in der Konfiguration übersteuert.