© ginasanders, 123RF.com

Sysadmin-Kolumnist Charly hat in diesem Monat den Salat und lässt deswegen ein angebotenes Steak zurückgehen. Alles klar? Herr Kühnast und ein tattriger Häuptling bitten zu Tisch.

“Salat schmeckt wesentlich besser, wenn man ihn kurz vor dem Verzehr durch ein saftiges Steak ersetzt” – solche Substitutionssprüche sterben trotz ihres homöopathischen Komikgehalts nicht aus. Auch Admins bekommen derart gestaltete Tipps: “Apache liefert statische Inhalte wesentlich schneller aus, wenn man ihn kurz vor dem Start durch Nginx ersetzt”. Der Spruch mag Vegetarier nicht mehr erregen, versetzt aber die Augen mancher Serveradmins in Kreisbewegung. Auch meine.

Ich soll nämlich gerade einen Apache 2.2, der fast nur statischen Content auswirft, auf Maximalleistung trimmen. Aus mehreren Gründen darf ich dabei den alten Indianer nicht in die Wüste schicken, der zwar der unangefochtene Häuptling der Flexibilität ist, aber in Sachen Performance die Verfolgung seiner Widersache gar nicht mehr aufzunehmen braucht.

Aber wenn ich dem Apachen nicht den Garaus machen darf, möchte ich ihn zumindest auf ein flotteres Pferd setzen, etwa durch einen flotten Cache wie Varnish [1]. Die Macher des Tools haben es von Grund auf als Caching-Instanz konzipiert, entsprechend mächtig fällt es aus. Ich könnte in der eigens dafür vorgesehenen Varnish Cache Language (VCL) komplexe Regelwerke entwerfen, für das Puffern statischer Webseiten reicht mir aber schon eine schlanke Konfiguration. Zunächst baue ich den Apache per »NameVirtualHost« und »Listen« so um, dass er künftig auf Port 8080 statt Port 80 lauscht, denn den soll Varnish übernehmen. Sein Cache wird dann Inhalte direkt an den Client weiterreichen.

Die meisten Distributionen haben Varnish an Bord. Debian und seine Derivate konfigurieren Varnish über die Datei »/etc/default/varnish« , Red Hat und Verwandte in »/etc/sysconfig/varnish« . Ich muss hier lediglich die Kommandozeilenparameter für den Startaufruf anpassen (»DAEMON_OPTS« ). Abbildung 1 zeigt die Konfiguration, die ich für meinen Apache-Beschleuniger benutze. Mit »-a :80« lege ich fest, dass Varnish auf allen IPv4- und IPv6-Adressen des Systems Verbindungen zu Port 80 entgegennimmt. Der Parameter »-b« verrät Varnish, wo der Apache sein Zelt aufgeschlagen hat.

Ein laufender Varnish lässt sich über ein Telnet-Interface steuern, dessen Adresse und Port ich mit »-T« angebe. Wegen der Sicherheit öffne ich den Port nur auf »localhost« , außerdem muss ich das Secret kennen, das in der Datei nach dem Parameter »-S« abgelegt ist. Hinter »-u« und »-g« verbergen sich erwartungsgemäß Benutzername und Gruppenzugehörigkeit.

Abbildung 1: Als reiner Apache-Beschleuniger reicht Vanish eine derartig simple Konfiguration.

Cache and Carry

Für die Performance ist die letzte Zeile mit dem Parameter »-s« die wichtigste, denn sie steuert Art und Größe des Caches. Den Cache kann ich im RAM oder auf einer Plattenpartition anlegen. Gebe ich hier

file, /var/cache/varnish.cache,50%

an, so benutzt Varnish den unter »/var/cache« bereitstehenden Plattenspeicher bis zur Hälfte. Dabei belegt das Tool den Platz nicht sofort, sondern die Cachedatei wächst erst nach und nach.

Kalte Platte

Allerdings sollte niemand von einem Plattencache Wunder erwarten. Mein Server verfügt zum Glück über 16 GByte RAM: Apache und Varnish nehmen sich davon ein Stückchen, aber 10 GByte darf ich dem Cache locker überantworten. Wäre ich zu knauserig, weicht Varnish ins Swap aus, und der Geschwindigkeitsvorteil ist hin. Ergo: »-s malloc,10g« , und der alte Indianer galoppiert wie ein junger. (jk)

Der Autor

Charly Kühnast administriert Unix-Systeme im Rechenzentrum Niederrhein. Zu seinen Aufgaben gehören Sicherheit und Verfügbarkeit der Firewalls und der DMZ.