Cloud-Dienstanbieter haben ein enormes Interesse an schnellem Internet. Das ist aber nicht nur abhängig von der Leitung und der sogenannten letzten Meile, sondern auch von der Konfiguration des HTTP-Servers, der die Anfragen entgegennimmt, an interne Mail-Server oder Datenbanken weiterleitet und die Antworten an den Browser des Benutzers ausliefert. Dabei ist es egal, ob die Anfragen aus dem internen Netzwerk oder von außerhalb kommen.
Was extern für Geschwindigkeit sorgt, kann intern nicht verkehrt sein - eigentlich. Wenn aber eine Site im Inter- oder Intranet extrem langsam ist, kann das auch an der Konfiguration des HTTP-Servers liegen. Das wird umso ärgerlicher, je mehr Programme einen HTTP-Server in Anspruch nehmen: Telefonanlagensoftware und Streaming-Programme bis hin zum Virtualisierungs-Hypervisor laufen im internen Netz darüber - ganz zu schweigen von SaaS-Produkten (Software-as-a-Service) und jeder weiteren webbasierten Software.
Um Apache flotter zu machen, hat Google vor gut einem halben Jahr das Open-Source-Modul "mod_pagespeed" veröffentlicht. Es soll Webseiten so beschleunigen, dass sie mit bis zu doppelter Geschwindigkeit im Browser des Benutzers ankommen - auf http://code.google.com/p/modpagespeed/ ist ein Video zu sehen, das den beschleunigten Seitenaufbau verdeutlichen soll. Dabei nutzt das Modul verschiedene Filter, um die auszuliefernden Daten zu minimieren: Das Caching werde verbessert, CSS- und Javaskript-Daten würden reduziert, HTML-Header zusammengefasst und Bilder abermals komprimiert - unter http://www.modpagespeed.com/ sind Beispiele für die unterschiedlichen Filter zu finden.
mod_pagespeed-Filter beschleunigt den Datenverkehr
Das mod_pagespeed-Modul gibt es unter http://code.google.com/intl/de-DE/speed/page-speed/download.html zum Download. Es ist für den Apache 2.2 programmiert und derzeit für Debian, Ubuntu und CentOS beziehungsweise Fedora (jeweils als 32- und 64-Bit-Version) verfügbar. Unter Debian und Ubuntu wird es auf einer Konsole mit dem Befehl:
dpkg -i mod-pagespeed-*.deb
apt-get -f install
installiert (in Ubuntu müssen Sie ein "sudo" voranstellen). In CentOS und Fedora führen Sie folgende Befehle als root aus:
yum install at
rpm -U mod-pagespeed-*.rpm
Die erste Zeile ist nur erforderlich, wenn Sie den Befehl "at" noch nicht installiert haben. Insgesamt werden damit vier Dateien installiert:
-
das Apache-Modul /usr/lib/apache2/modules/mod_pagespeed.so,
-
die Cron-Datei /etc/cron.daily/mod-pagespeed,
-
die Datei /etc/apache2/mods-available/pagespeed.load und
-
die Datei /etc/apache2/mods-available/pagespeed.conf.
Nach der Installation muss der HTTP-Server einmal neu gestartet werden mit dem Befehl "/etc/init.d/apache2 restart" ("sudo" in Ubuntu voranstellen). Danach arbeitet das pagespeed-Modul bereits. Das Apache-Modul macht die eigentliche Arbeit. Es speichert die Daten, die der HTTP-Server ausliefert, in den Verzeichnissen /var/mod_pagespeed/cache und /var/mod_pagespeed/files zwischen.
Die Cron-Datei /etc/cron.daily/mod-pagespeed richtet das Google-Repository für eventuelle Paket-Updates ein. Diese Funktion kann der Debian-Benutzer zudem selbst kontrollieren, indem er die Datei /etc/default/mod-pagespeed erzeugt. In dieser Einstellungsdatei kann er zwei Variablen verwenden: "repo_add_once" und "repo_reenable_on_distupgrade". Diese sind für ein Distributions-Update gedacht, bei dem die Repositories auf Debian-Standards gesetzt werden. Setzt er beide Parameter auf "true", wird das Google-Repository automatisch wieder als Datenquelle eingerichtet.
Weniger Daten ausliefern mit dem Deflate-Modul
Die Datei /etc/apache2/mods-available/pagespeed.load lädt das Apache-Module mod_deflate.so, falls dies noch nicht geschehen ist. Das Deflate-Modul komprimiert Serverdaten mithilfe der Programmbibliothek zlib, bevor sie über das Netzwerk an den Client gesendet werden. Es kann in der Serverkonfiguration oder auch in Konfigurationsabschnitten für virtuelle Hosts eingerichtet werden. Insgesamt gibt es für das Deflate-Modul fünf sogenannte Direktiven:
-
DeflateBufferSize: Mit dieser Direktive wird die Größe der Fragmente bestimmt, die zlib auf einmal komprimiert. Die Vorgabe ist 8096.
-
DeflateCompressionLevel: Hier wird festgelegt, wie hoch die zlib-Kompression sein soll. Voreingestellt ist die zlib-Standardkompression. Es können Werte zwischen 1 (geringe Kompression) und 9 (höchste Kompression) gewählt werden. Beachten Sie, dass eine höhere Kompression auch mehr Rechenzeit beansprucht. Die Direktive kann ab der Apache-Version 2.0.45 verwendet werden.
-
DeflateFilterNote: Mit dieser Direktive kann der Administrator sehen, wie hoch die Kompressionsrate ist. Denn das Ergebnis wird mit in die Logdateien des HTTP-Servers geschrieben und kann statistisch ausgewertet werden.
-
DeflateMemLevel: Diese Direktive legt fest, wie viel Speicher von zlib für die Kompression genutzt werden soll. Möglich sind Werte von 1 bis 9, die Vorgabe ist 9.
-
DeflateWindowSize: Für diese Direktive sind Werte von 1 bis 15 möglich. Die Vorgabe ist 15. Generell gilt laut Apache-Dokumentation: Je höher der Wert, desto höher ist die zu erwartende Kompressionsrate.
Deflate-Modul konfigurieren
Nicht jeder Browser kann mit komprimierten Inhalten umgehen. Darüber hinaus ist es nicht sinnvoll, komprimierte Daten wie etwa Bilder noch weiter zu komprimieren. Diesem kann man mit der Konfiguration des Deflate-Moduls Rechnung tragen. Die Zeile:
AddOutputFilterByType DEFLATE text/html text/plain text/xml
etwa sorgt dafür, dass nur die MIME-Typen "text/html", "text/plain" und "text/xml" komprimiert werden. Die folgende Konfiguration aus der Apache-Dokumentation komprimiert hingegen alles außer Bilder.
<Location />
# Insert filter
SetOutputFilter DEFLATE
# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html
# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip
# MSIE masquerades as Netscape, but it is fine
# BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# NOTE: Due to a bug in mod_setenvif up to Apache 2.0.48
# the above regex won't work. You can use the following
# workaround to get the desired effect:
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
# Don't compress images
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png)$ no-gzip dont-vary
# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
</Location>
In der Zeile mit "SetOutputFilter DEFLATE" wird die Kompression aktiviert. Fordert nun ein Netscape-4.x-Browser Daten an, werden nur solche vom Typ "text/html" komprimiert. An die Netscape-Browser 4.06, 4.07 und 4.08 werden überhaupt keine komprimierten Daten ausgeliefert. In der zweitletzten Anweisung steht schließlich, dass Daten mit den Endungen .gif, .jpg, .jpeg und .png nicht komprimiert werden sollen. Wer darüber hinaus noch einen Proxyserver einsetzt, benötigt auch die letzte Anweisung, damit keine falschen Daten ausgeliefert werden.
Sie können die Kompression auch einfach für bestimmte MIME-Typen vorgeben. Die Zeilen
<Directory "/your-server-root">
AddOutputFilterByType DEFLATE text/html
</Directory>
beispielsweise komprimieren im Server-Root-Verzeichnis und den darunterliegenden Verzeichnissen alle HTML-Dateien, lassen aber die anderen wie Bilder und Dokumente unberücksichtigt.
Kompressionsrate mitloggen
Wie oben erwähnt, dient die Direktive DeflateFilterNote dazu, die Kompressionsrate in die Logdateien zu schreiben. Apache gibt in der Serverdokumentation ein Beispiel dafür :
DeflateFilterNote ratio
LogFormat '"%r" %b (%{ratio}n) "%{User-agent}i"' deflate
CustomLog logs/deflate_log deflate
Wer noch akkurater protokollieren möchte, kann mithilfe der Parameter "Input" und "Output" in der Konfigurationsdatei auch die Byteanzahl vor und nach dem Komprimieren mitschreiben lassen:
DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
CustomLog logs/deflate_log deflate
Damit erhält der Administrator einen guten Überblick, welche Daten wie hoch komprimiert ausgeliefert werden. Übrigens: Der Parameter "Ratio" ist der Vorgabewert und muss aus dem Grund im ersten Beispiel nicht angegeben werden.
Pagespeed-Modul konfigurieren
In der Datei /etc/apache2/mods-available/pagespeed.conf wird das Google-Pagespeed-Modul konfiguriert. Es wird zwischen eine IfModule-Direktive gestellt. Innerhalb der If-Abfrage können zwei Routinen aufgerufen werden, die Statistiken liefern: "mod_pagespeed_statistics" und "mod_pagespeed_beacon". Die erste Routine zeigt Serverstatistiken, aus denen man die Latenzzeit berechnen kann, um so die Effizienz verschiedener Beschleunigungsmethoden zu messen. Will man auf diese Statistiken verzichten, ist das Kommentarzeichen in der Zeile
# ModPagespeedStatistics off
zu löschen.
Ein wichtiger Teil der Konfiguration ist die Anweisung ModPagespeedRewriteLevel. In der Voreinstellung sind hier die sogenannten Core-Filter eingeschaltet, also die folgenden neun der insgesamt 21 Filter:
-
add_head: Fügt ein head-Tag im HTML-Code hinzu, falls es vor einem body-Tag keinen findet (der Filter bereitet nach Entwickleraussagen keine Probleme).
-
combine_css: Kombiniert unter bestimmten Voraussetzungen mehrere CSS-Dateien zu einer (Javaskript in Kombination mit link-Einträgen kann sich fehlerhaft verhalten).
-
extend_cache: Fügt in URL-Referenzen einen Hash-Wert ein, sodass sich die URL ändert, sobald die Ressource geändert wird. So wird alter Inhalt im Browser-Cache nicht erneut referenziert (Javaskript-Code, der bestimmte Dateinamen erwartet, kann zu anderen Ergebnissen führen).
-
inline_css: Fügt kleine externe CSS-Daten direkt in den HTML-Code ein (kann mit link- oder style-Tags Probleme bereiten).
-
inline_javascript: Fügt kleine externe Javaskript-Daten direkt in den HTML-Code ein (kann mit script-Tags Probleme bereiten, die sowohl src-Attribute als auch Inline-Daten enthalten).
-
rewrite_css: Checkt verlinkte und Inline-CSS-Daten und minimiert das CSS in style-Blöcken und link-Referenzen (kann zu Problemen mit schlecht kodierten CSS führen, aber auch mit Javaskript-Code, der exakte URLs verlangt).
-
rewrite_images: Entfernt unter anderem Metadaten wie Copyright-Informationen aus den Bildern (der Filter bereitet nach Entwickleraussagen keine Probleme). rewrite_images ruft auch noch die Filter insert_image_dimensions (fügt width- und height-Attribute hinzu), inline_images (ersetzt kleinere Bilder durch data-URLs), recompress_images (entfernt Metadaten und wandelt gif- in png-Dateien um) und resize_image (ändert die Bildgröße, wenn im img-Tag kleinere Werte für width und height stehen) auf.
-
rewrite_javascript: Mimimiert Javaskript-Code, indem Leerzeichen, Tabulatoren und Kommentare entfernt werden (dieser Filter wird als riskant betrachtet und ist daher standardmäßig nicht eingeschaltet).
-
trim_urls: Kürzt URLs aus scr- oder href-Attributen relativ zur Basis (der Filter bereitet nach Entwickleraussagen keine Probleme).
Filterfunktionen nutzen
Wollen Sie einen der Filter nicht nutzen, schalten Sie ihn mithilfe der Anweisung "ModPagespeedDisableFilters" aus. Als Argumente geben Sie hier einen oder - mit Kommata getrennt - mehrere Filter an:
ModPagespeedDisableFilters rewrite_javascript,inline_javascript
Möchten Sie umgekehrt weitere Filter zuschalten, nutzen Sie die Anweisung "ModPagespeedEnableFilters". Die Beschreibung der übrigen elf Filter finden Sie in der Dokumentation unter http://code.google.com/intl/de-DE/speed/page-speed/docs/filters.html. Bevor Sie einen Filter einschalten, lesen Sie die dortige Dokumentation unbedingt. Denn es wird beispielsweise standardmäßig der resize_image-Filter eingeschaltet, was zu extrem hohen CPU-Lasten führen kann. Wird es zu viel, reduzieren Sie den Wert in der Anweisung ModPagespeedImageMaxRewritesAtOnce auf einen Voreinstellungswert unter acht, etwa:
ModPagespeedImageMaxRewritesAtOnce 4
Wer das Pagespeed-Modul nicht mehr nutzen und abschalten möchte, muss das Paket übrigens nicht löschen. Es genügt, die Anweisung
ModPagespeed on
zu Anfang der Konfiguration auf "off" zu setzen. Tipp: Das Pagespeed-Modul können Sie auch über Directory-Direktiven oder mithilfe von .htaccess-Dateien auf bestimmte Verzeichnisse eingrenzen. Denken Sie aber immer daran, nach Änderungen der Konfiguration diese neu zu laden oder den Apache neu zu starten. (hal)