Sicherheitswarnung: Bitte keine Version älter als 1.11 verwenden!

Das Cache-Modell von gzip_cnc

Zielsetzung

Seiten eines Web-Auftritts werden in den meisten Fällen sehr viel öfter gelesen, als sich ihr Inhalt ändert - jedenfalls dann, wenn es sich um statische Seiten handelt.

Der Inhalt dynamischer Seiten (etwa der Ausgaben einer Suchmaschine) ändert sich dagegen bei jeder neuen Anforderung der Seite - sei es

Komprimierte Versionen statischer Dokumente

Im Allgemeinen kann man einem URL nicht ansehen, ob der zugehörige Inhalt statischer oder dynamischer Natur ist - das liegt allein an der Konfiguration des Webservers.

Der Anbieter eines Web-Auftritts weiß jedoch selbst genau, welche seiner eigenen Seiten statisch sind und welche dynamisch. Er kann also seine statischen Seiten auch in komprimierter Form anbieten - und falls er Rücksicht auf alte Browser nehmen muß, welche komprimierte Inhalte noch nicht verarbeiten können, dann kann er beide Formen der Seiten anbieten und (anhand der vom Browser gesendeten HTTP-Header) den Webserver entscheiden lassen, welche der beiden Formen ausgeliefert werden soll.

Pflege der komprimierten Versionen

Das bedeutet natürlich, daß der Betreiber jedesmal, wenn er den Inhalt einer seiner Seiten ändert, darauf acht geben muß, die komprimierte Form dieser Seite ebenfalls zu ändern.

Wenn er das vergißt, dann liefert der Webserver den Besuchern je nach deren Browser-Version und -Einstellung teilweise die aktuelle, teilweise aber eine veraltete Version der Seite aus - der Webserver weiß ja nicht, daß beide Dateien eigentlich denselben Inhalt besitzen sollen.

Automatisierung

Viel komfortabler wäre es doch, wenn der Webserver (der ja ohnehin entscheiden muß, welche der beiden Formen er ausliefern soll) diese beiden Aufgaben auch gleich mit übernehmen könnte:

Der Seitenanbieter sollte sich ausschließlich um die Originale seiner Seiten kümmern müssen.

Genau das leistet gzip_cnc: Es erweitert den Apache-Server um einen Handler, der zu jeder Anforderung, für deren Bearbeitung er als zuständig deklariert wurde, wahlweise auch eine komprimierte Form herstellen, pflegen und ausliefern kann.

Und diese Herstellung erfolgt so selten wie möglich (um CPU-Zeit zu sparen), aber so oft wie nötig (um niemals eine veraltete Version des Inhalts auszuliefern).

Ablageort der komprimierten Dokument-Formen

Um direkt diejenige Form der bedingten Auslieferung von Seiteninhalten nutzen zu können, welche der Apache-Webserver selbst zur Verfügung stellt (Content Negotiation), müßte gzip_cnc jeweils die komprimierte Form innerhalb desselben Verzeichnisses ablegen, in dem sich auch die Original-Datei befindet.

Ein solches Vorgehen hätte allerdings zwei Nachteile:

gzip_cnc hat sich daher dafür entschieden, den Dokumentbaum, für den das Programm zuständig ist, in einem separaten Cache-Verzeichnisbaum komplett nachzubauen und nur innerhalb dieses Caches, verborgen vor dem Webserver, die komprimierten Formen der Datei-Inhalte abzulegen.

Verzeichnisse und URLs

Ein Web-Auftritt kann aus einer Reihe getrennter Verzeichnisbäume bestehen, welche über Konfigurationsanweisungen des Webservers in den gemeinsamen URL-Raum eingeblendet werden.

Würde gzip_cnc sich bei der Verwaltung seiner komprimierten Formen am Pfadnamen der Original-Datei orientieren, dann müßte es potenziell den gesamten Verzeichnisbaum des Betriebssystems nachbauen - innerhalb dieses Verzeichnisbaum selbst! Auch unter der Annahme, daß nur ein kleiner Teil des Verzeichnisbaum (innerhalb des URL-Raums) tatsächlich für Besucher des Web-Auftritts sichtbar ist, würden auf diese Weise unnötig lange Verzeichnispfade entstehen (mit der zusätzlichen Gefahr, an eine Beschränkung des jeweiligen Betriebssystems zu stoßen).

Daher bezieht sich gzip_cnc innerhalb seines Caches nicht auf Pfadnamen, sondern auf URLs der Original-Dateien und baut den URL-Baum des Web-Auftritts nach. (Und zwar den gesamten Baum ab der Wurzel der Domain.)
Sollte dieselbe Datei unter mehreren URLs ansprechbar sein, dann würde gzip_cnc also für jeden dieser URLs eine entsprechende Cache-Datei anlegen. (Es sei denn, der Betreiber, der durch einen komplexen Einsatz von Konfigurationsanweisungen diese Situation ja selbst geschaffen hat, fügt innerhalb des Cache-Baums an denjenigen Stellen, wo zwei URLs eine identische Bedeutung haben sollen, entsprechende Verbindungen ein - in UNIX wäre dies beispielsweise durch die Verwendung von symbolic links möglich.)

Verbesserungsmöglichkeiten

Es wär denkbar, die Cache-Verzeichnisnamen durch den Einsatz einer geeigneten Hash-Funktion noch weiter abzukürzen - das Apache-Modul mod_proxy tut dies beispielsweise. Sollte sich die Verwendung der Original-URLs als Pfadnamen innerhalb des Cache-Baums eines Tages als Problem erweisen, dann wäre an dieser Stelle eine entsprechende Änderung problemlos möglich.

Außerdem ist nicht allgemein vorhersehbar, wie schnell das Dateisystem (welches ggf. eine Vielzahl komprimierter Dateien innerhalb des Cache-Baums aufnehmen soll) sehr viele Dateien im selben Verzeichnis verarbeiten kann - eine sequenzielle Suche nach der gewünschten Datei könnte die Rechenlast auf dem Server erhöhen und damit die Auslieferung der Datei verlangsamen.

(Michael Schröpl, 2002-08-04)