Sicherheitswarnung: Bitte keine Version älter als 1.11 verwenden!

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

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

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:

  1. die Verfügbarkeit eines Perl5-Interpreters - denn gzip_cnc ist ein Perl-Skript.
  2. die Möglichkeit zur Ausführung eigener CGI-Anwendungen - denn gzip_cnc ist eine solche.
  3. ein Komprimierungswerkzeug. Dafür gibt es diverse Möglichkeiten:
    1. ein auf dem Server installiertes Perl-Modul Compress::Zlib oder
    2. 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
      werden kann.
    gzip_cnc probiert beide Alternativen aus und nimmt, was es geboten bekommt - es bevorzugt dabei das Perl-Modul (ein Systemkommando aufzurufen erfordert jedes Mal den Start eines zusätzlichen Prozesses).
  4. 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.
  5. 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.
  6. der Möglichkeit, innerhalb von .htaccess-Dateien Direktiven der Klasse FileInfo 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 Direktive AllowOverride 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ß

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

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

- 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:

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)