gzip_cnc - ein Apache-Handler zur Auslieferung komprimierter Inhalte
Worum geht es hier eigentlich?
gzip_cnc ist ein in Perl geschriebenes CGI-Skript. Es muß als Handler in den Apache-Webserver eingebunden werden und kann dann die angeforderten statischen Seiteninhalte in gzip-komprimierter Form an (hinreichend fähige) Web-Browser ausliefern.
Das Programm
- verwendet Content-Negotiation zur Feststellung, ob der Web-Browser bereit ist, gzip-codierte Inhalte zu empfangen, und
- speichert für jedes ausgelieferte Dokument die aktuellste Version des Inhalts in komprimierter Form innerhalb seines eigenen Cache-Baums.
Aus all diesen Eigenschaften ist der Name des Programms entstanden.
(Ein kryptischer Name mag zwar weder leicht zu merken noch leicht auszusprechen zu sein - aber als eindeutiger Begriff für Suchmaschinen hat er auch wieder seine Vorteile ...)
Warum gzip_cnc - es gibt doch mod_gzip?
Richtig. Wenn es darum geht, den Apache-Webserver Seiteninhalte - besonders dynamisch erstellte - in komprimierter Form ausliefern zu lassen, ist das Apache-Modul mod_gzip die beste (mir bekannte) Lösung. Wenn Du also
- selbst ein Provider bist oder wenigstens
- Server-Hosting verwendest und daher Deinen Webserver um ein 3rd-party-Modul wie mod_gzip erweitern darfst,
dann bist Du dort am besten aufgehoben.
Aber was ist, wenn Du eine normale Homepage hast, die im Wesentlichen aus statischen Seiten besteht und dafür einfach nur einen normalen Webspace nutzen darfst, mit einer Handvoll Zusatzmöglichkeiten wie CGI und .htaccess
- aber Dein Provider nicht bereit ist, mod_gzip auf diesem Server zu installieren? Für dieses Einsatzfeld, typisch für viele kleinere Websites, ist gzip_cnc gedacht.
Welche Anforderungen kann gzip_cnc komprimieren?
gzip_cnc kann nur Anforderungen nach statischen Inhalten komprimieren.
Das ist eine grundsätzliche Einschränkung des Programms selbst - denn um dynamische Inhalte komprimieren zu können, müßte es diese dynamischen Inhalte nach deren Erzeugung, aber vor deren Auslieferung durch den Webserver in die Finger bekommen. mod_gzip kann das - weil es ein Apache-Modul ist; gzip_cnc ist 'nur' ein Apache-Handler, und es macht wenig Sinn, diesem Handler beizubringen, die Funktion anderer Handler (wie etwa CGI oder SSI) teilweise nachzubilden, was der Apache-Server selbst erheblich performanter erledigen kann.
Welche Dateitypen kann gzip_cnc verarbeiten?
Die aktuelle Version von gzip_cnc komprimiert nur einen (konfigurierbaren) Dokumenttyp, mit dem voreingestellten Wert für HTML-Dokumente - das ist immerhin die Masse der im WWW vorliegenden Dateien.
Der Grund dafür, daß hierbei überhaupt eine Einschränkung existiert, ist, daß gzip_cnc selbst verstehen muß, was es da gerade komprimiert (weil es diese Information auch an den Browser senden muß), aber vom Apache-Server leider nicht gesagt bekommt, wofür dieser laut seiner eigenen Konfiguration den vorliegenden Inhalt hält (weil wir 'nur' ein Handler sind und kein Modul und deshalb auf die Apache-Konfiguration nicht direkt zugreifen können).
Es ist einfach, diesen Dokumenttyp zu ändern, und es wäre auch nicht sonderlich schwierig, weitere Dokumenttypen einzubauen - es läuft darauf hinaus, eine ähnliche Abbildungstabelle zu verwenden, wie sie auch schon vom Apache-Server selbst verwendet wird. Aber Du kannst sehr wohl mehrere gzip_cnc-Instanzen parallel einsetzen und jede von ihnen für die Behandlung eines MIME-Typs Deiner Wahl konfigurieren. Und bei Verwendung der Konfiguration über Environment-Variablen geht dasselbe sogar mit nur einer einzigen Instanz von gzip_cnc.
Kann ich gzip_cnc für meinen Webspace verwenden?
Um gzip_cnc nutzen zu können, ist eine Reihe von Voraussetzungen notwendig:
- die Verfügbarkeit eines Perl5-Interpreters - denn gzip_cnc ist ein Perl-Skript.
- die Möglichkeit zur Ausführung eigener CGI-Anwendungen - denn gzip_cnc ist eine solche.
- ein Komprimierungswerkzeug. Dafür gibt es diverse Möglichkeiten:
- ein auf dem Server installiertes Perl-Modul
Compress::Zlib
oder - ein
gzip
-Komprimierungsprogramm, welches- bei UNIX-artigen Betriebssystemen als Systemkommando
gzip
- oftmals bereits vorhanden ist oder
- aus dem Quelltext erzeugt bzw.
- bei Windows-artigen Betriebssystemen
- als Programmdatei
gzip.exe
installiert
- als Programmdatei
- bei UNIX-artigen Betriebssystemen als Systemkommando
- ein auf dem Server installiertes Perl-Modul
- ein Apache-Webserver - denn die Art und Weise, wie gzip_cnc sich um die Auswertung der in komprimierter Form zu beantwortenden Seitenzugriffe bewirbt, ist Apache-spezifisch.
- der Möglichkeit, für den eigenen URL-Raum die Webserver-Konfiguration zu ergänzen, wahrscheinlich durch den Einsatz von
.htaccess
-Dateien - denn gzip_cnc muß als zuständiges Programm für die Behandlung der zu komprimierenden Seitenzugriffe in die Apache-Konfiguration eingebunden werden. - der Möglichkeit, innerhalb von
.htaccess
-Dateien Direktiven der KlasseFileInfo
zu verwenden - denn zu dieser Klasse gehört diejenige Direktive, mit deren Hilfe gzip_cnc als zuständiges Programm für die Behandlung der zu komprimierenden Seitenzugriffe definiert werden kann. Damit dies erlaubt ist, muß für den entsprechenden Webspace die DirektiveAllowOverride FileInfo
in der zentralen Apache-Konfiguration gesetzt worden sein.
Auf den ersten Blick mag das alles schrecklich kompliziert klingen und diese Kombination von Voraussetzungen eher unwahrscheinlich erscheinen. Aber UNIX (inklusive beliebiger Linux-Varianten), Apache und Perl sind ein bewährtes Team und bei den meisten Providern verfügbar; eigene CGI-Skripte und .htaccess
(letzteres oftmals für die Zugangskontrolle zu geschützten Bereichen des Web-Auftritts eingesetzt) sind übliche Zusatzfeatures, die zwar selten bei kostenlosem Webspace vorhanden, aber normalerweise schon im kleinsten Angebot-Paket kommerzieller Provider enthalten sind.
Das wahrscheinlichste Problem ist wohl eine Einschränkung der innerhalb von .htaccess
verwendbaren Direktiven - dies sollte man also als erstes klären, sei es durch Nachfrage beim Provider oder einfach durch Ausprobieren.
Wieviel zusätzliche Last verursacht gzip_cnc auf dem Server?
Für einen kommerziellen Server mit hohen Seitenabrufzahlen wird es nicht geeignet sein - aber der sollte ja ohnehin mod_gzip verwenden.
Im Wesentlichen wird jeder Zugriff auf eine statische Seite ersetzt durch den Aufruf eines CGI-Skripts, das nicht viel mehr tut, als den Inhalt einer Datei zu lesen und ihn an den Browser auszuliefern, wie das auch der Webserver normalerweise tun würde.
Der Trick ist, daß
- durch die Verwendung des Cache-Modells tatsächlich nur sehr selten Daten wirklich komprimiert werden müssen und
- die Auslieferung komprimierter Inhalte, deren Größe nur 20-40% derjenigen des unkomprimierten Originals beträgt, schneller sein muß, als immer die größeren Original-Dateien auszuliefern.
Andererseits bezahlst Du den Preis von einem CGI-Aufruf für jede angeforderte Seite - Du wirst also ein leistungsfähiges Implementierungsmodell zur Ausführung von CGI-Anwendungen auf Deinem Server nutzen wollen. Auf meinem Webspace nutzt der Apache-Server mod_fastcgi
, und obwohl die Maschine, auf der dieser Server läuft, nur ein Pentium 400 ist, dauert es
- lediglich etwa 0.04 CPU-Sekunden für jede Seitenauslieferung (fast unabhängig von der Dokumentgröße) und
- zwischen ein- und fünfmal so viel für jede Seitenkomprimierung (eine 400-KB-Seite auf 80 KB zu komprimieren, dauerte 0.21 CPU-Sekunden, das ist der gemessene Maximalwert auf meiner Domain).
Die Protokollfunktion von gzip_cnc nennt Dir die entsprechenden Werte für Deine Maschine.
Ich beobachte allerdings, daß trotz etwa täglicher Änderungen meiner am häufigsten angeforderten Dokumente während der Entwicklungsphase von gzip_cnc
- immer noch 97% aller Seitenzugriffe nur bereits komprimierte Inhalte aus dem Cache (oder unkomprimierte Originalseiten) abrufen und
- nur 3% die Erzeugung oder Aktualisierung des Inhalts einer Cache-Datei bewirken
- und auf lange Sicht sollte diese Rate eher sinken (abhängig davon, wie oft Du den Inhalt Deiner Dokumente änderst).
Die Kosten für den Aufbau des Cache sind also nahezu vernachlässigbar, und nur die Kosten für die Auslieferung von Seiten, d. h. für den Aufruf des CGI-Skripts, sind wirklich von Bedeutung.
Wieviel zusätzlichen Platz auf der Festplatte des Servers belegt der Cache von gzip_cnc?
Ein guter Schätzwert für den vom Cache-Baum belegten Festflattenplatz ist ein Drittel des Speicherplatzes für alle unkomprimierten Original-HTML-Dateien.
Der Cache-Baum muß zwei Arten von Objekten aufnehmen:
- komprimierte Dateien, bei denen Du davon ausgehen kannst, daß kleine HTML-Dateien (10 KB und weniger) um etwa 40-70% und größere Dateien um etwa 60-90% komprimiert werden können - abhängig vom Grad der Redundanz innerhalb dieser Dokumente. Normale Textdateien lassen sich üblicherweise um Faktor 3 komprimieren; HTML-Dokumente, die wiederholt ähnliche tags-Muster wie z. B. Tabellen enthalten, können auch mal um Faktor 10 oder gar noch besser komprimierbar sein.
- Verzeichnisse, die sich überhaupt nicht komprimieren lassen, da sie etwa dieselbe Anzahl von Einträgen enthalten wir ihre Original-Instanz innerhalb des Webspace.
Der exakte Platzbedarf Deines Cache-Baums hängt also ein wenig von der Anzahl Deiner Verzeichnisse ab, hauptsächlich aber vom Grad der Redundanz innerhalb Deiner Dokumente.
Und als Merkregel gilt: Wenn Dein Cache-Baum ein Drittel des Original-Webspace belegt (inklusive des Overhead für die Verzeichnisse), dann werden Deine Besucher ein Drittel des Original-Dateivolumens (inklusive des Overheads für die HTTP-Header) ausgeliefert bekommen und somit dreimal kürzere Antwortzeiten erleben können.
Falls Du einen großen Anteil an anderen Seiten als statische HTML-Dateien auszuliefern hast, können die Zahlen bei Deiner Installation natürlich entsprechend abweichen.
(Michael Schröpl, 2004-01-11)