nicht angemeldet
Hi Mathias,
Wieso unterhält Squid eigentlich ein Cache für die
statischen unkomprimierten Seiten, sie könnten doch
wie vom HTTPd direkt aus dem Dateisystem gelesen
werden und müssten nicht als Kopie im Cache
vorliegen?
ein eigener Cache im Hauptspeicher ist noch wesentlich schneller als ein Festplattenzugriff, bei dem ja immerhin eine Betriebssystemfunktion aufgerufen werden muß.
Selbst wenn Du ein sehr gut getunetes Dateisystem mit eigenem Caching und Hashfunktion für die Pfad-Übersetzung und jeder denkbaren Optimierung einsetzen würdest, dann würdest Du die Qualität eines Squid nur erreichen, aber kaum übertreffen können, weil der diese Optimierungen eben auch alle enthält.
Und der Ressourcenbedarf des Squid ist einfacher per Konfiguration auf den konkreten Einsatzfall abzustimmen, als dafür beispielsweise den UNIX-Kernel der Maschine entsprechend zu konfigurieren (falls der Dateisystem-Treiber sich genauso flexibel einstellen ließe).
Der Apache wird dadurch doch nur entlastet, weil
dieser dann nur noch für die dynamischen Seiten
zuständig wäre und die on-the-fly-Komprimierung der
statischen Seiten entfallen würde, verstehe ich das
richtig?
Der Apache muß für die Verarbeitung eines HTTP-Zugriffs sehr viel mehr tun als ein Proxy-Cache - weil er viel mehr Möglichkeiten unterstützen muß.
Beispielsweise muß der Apache die diversen Konfigurationsabschnitte für den zentralen Host, für Virtual Hosts, für <Directory>- und <Files>- und viele andere Abschnitte (ganz zu schweiigen von möglicherweise im gesamten Dateisystem verstreuten und _dynamisch_ einzulesenden .htaccess-Dateien!) semantisch korrekt übereinander mappen, um überhaupt erst mal die _Abbildung_ eines URL auf einen Dateinamen vorzunehmen und _danach_ zu erkennen, ob das ein statischer oder ein dynamischer Zugriff war!
Und das für _jeden_ HTTP-Zugriff immer wieder - der Inhalt einer .htaccess-Datei kann sich beispielsweise on the fly ändern, ohne daß dafür ein Neustart des Webservers notwendig sein darf.
Woraus Du lernen kannst: Wenn .htaccess eingesetzt wird, dann gibt es gar keine wirklich 'statischen' Dateizugriffe im Apache, weil schon die Bedeutung eines URL eine aufwändige Berechnung erfordert, deren Ergebnis nicht gecached werden _darf_.
Also: Finger weg von .htaccess bei performance-optimierten Maschinen - Server Authentication gehört dann in die httpd.conf, welche nur beim Start des Apache einmalig eingelesen wird.
Man kann einen Apache ohne einen Teil dieser Fähigkeiten betreiben, wenn man bestimmte Module nicht mit einbindet. Aber ein großer Teil dessen, was ich gerade beschrieben habe, ist Bestandteil des Apache-Kerns - das kriegst Du nicht raus, ohne den Apache erheblich umzuschreiben.
Diesen ganzen Aufwand braucht ein reiner Proxy-Cache nicht - der kommt mit einer statische Abbildung zwischen URLs und Cache-Positionen aus, die als Hash komplett im Hauptspeicher gehalten werden kann.
Wieso werden die statischen Seiten eigentlich erst
mit mod_gzip komprimiert und liegen nicht schon
komprimiert im Dateisystem, oder tun sie das?
Völlig richtig gedacht: mod_gzip unterstützt in der Tat auch eine spezialisierte Form der Negotiation für genau die Unterscheidung zwischen unkomprimierten und komprimierten statischen Seiten.
(Der Apache selbst könnte das ebenfalls, wenn man mod_negotiation dazu nimmt und entsprechend konfiguriert - bei mod_gzip ist das einfach eine Direktive mit den Werten "an" und "aus".)
Dazu muß man allerdings die komprimierte Version zu jeder einzelnen Datei neben das Original legen und mit einer passenden Endung versehen. Man muß diese Dateien also erst mal aktiv herstellen. Das kann bei einigen tausend Dateien des Self-Portals ganz schön lästig sein.
Bis mod_gzip 1.3.19.1a merkte mod_gzip zudem nicht, wenn die Original-Datei aktualisiert worden war - es war also möglich, daß eine veraltete statisch vorkomprimierte Version ausgeliefert wurde, wenn der Betreiber seine Dateien nicht ständig überwachte und die komprimierten Versionen aktiv aktualisierte.
mod_gzip 1.3.19.2a merkt das Veralten statischer vorkomprimierter Dateien automatisch, liefert in diesem Falle die Original-Datei aus und schreibt eine Warnung ins Apache-Log.
mod_gzip 1.3.26.1a unterstützt nun seit ein paar Wochen erstmals das Feature, die statisch vorkomprimierten Dateien in diesem Falle _aktiv_ mit einer neuen komprimierten Version des geänderten Originals zu _überschreiben_, also seinen 'Cache' aktiv zu pflegen. Schreibzugriffe eines Apache-Moduls in den URL-Raum eines Anwenders sind natürlich nicht jedermanns Sache - wer ein solches Feature aktiv einschaltet, muß wissen, worauf er sich eingelassen hat, und insbesondere die dafür erforderlichen Zugriffsberechtigungen sicherstellen.
All das, was Du als sinnvoll hergeleitet hast, haben auch Christian Kruse und ich so gesehen - und Christian hat es in den vergangenen Monaten schrittweise eingebaut. Seit mod_gzip 1.3.26.1a ist die Auslieferung statisch vorkomprimierter Versionen von Dateien in mod_gzip ein wirklich gut nutzbares Feature.
Was vielleicht noch fehlt, ist der aktive Betrieb eines eigenen, selbst _angelegten_ Cache komprimierter Varianten außerhalb des URL-Baums (unsichtbar für den Webspace-Benutzer und dann tauglich für den Massenhoster-Betrieb) - so ähnlich, wie gzip_cnc das bereits als Machbarkeitsstudie vorgeführt hat.
Falls mod_gzip irgendwann mal zuverlässig dynamische von statischen Responses unterscheiden können sollte (was leider nicht so völlig trivial zu sein scheint), dann wäre dies der nächste Schritt, der dort eingebaut werden könnte - mod_proxy hat vorgemacht, wie man so etwas lösen kann.
mod_proxy hat allerdings eine eigene Konfigurationssprache dafür, was gecached werden sollte und was nicht. Diese in mod_gzip noch einmal zu implementieren kann's nicht sein.
Bis auf selfhtml.teamone.de/cgi-bin/* könnte,
falls es möglich ist, den Proxy anweisen, dass
die Anfragen an die sich sowieso nicht ändernden
Seiten vorerst gar nicht an den Apache weiterleitet.
Dazu sendet der Apache an den Squid entsprechende "Expires:"- und "Cache-Control:"-Header.
Der Squid verhält sich dabei wie ein gut konfigurierter Browser und glaubt diesen Aufbewahrungsfristen - er fragt also den Apache erst nach ein paar Stunden oder gar Tagen wieder, ob der inzwischen eine neuere Version dieser Datei hat. So kommen diese gut 90% weniger an Apache-Anfragen zum großen Teil zustande.
Bedenke, daß Du beispielsweise bei Änderungen von Feature-Artikeln, bei Korrekturen in SelfHTML, bei einem Update der Alpentouren usw. nicht erst die Proxy-Konfiguration ändern willst, bevor die neuen Seiten zu den Besuchern gelangen können. Über Aufbewahrungsfristen regelt sich die Sache automatisch von selbst - bei trotzdem sehr wenigen Zugriffen auf den Apache-Server (welche noch dazu sehr oft conditional-GET-Zugriffe sein können, die mit HTTP-304 statt der Auslieferung von Daten beantwortet werden dürfen).
Mir kommt es vor, als wäre ein Cache als Zusatz zum
Apache in einer gewissen Weise unangebracht, weil
Squid keinen Zugriff auf die statischen Inhalte hat
und somit nicht selbst prüfen kann, ob die Datei
geändert wurde, sondern erst den Apache bemühen
muss, obwohl er durchaus Zugriff auf die Dateien
hätte, aber selbst nur ausliefern und
zwischenspeichern kann, aber nicht selbst
komprimieren kann...
Die Apache-Konfiguration liefert dem Squid Anhaltspunkte für eine Strategie, nach welcher er sich so viele Fragen wie möglich _sparen_ kann.
Bedenke, daß das Prüfen selbst auch einiges kosten würde! Gar nicht prüfen, sondern den Aufbewahrungsfristen glauben, ist das Allerschnellste.
Deshalb sollte man in seinem Browser auch unbedingt "automatisch" als Caching-Strategie einstellen, wenn man den HTTP-Headern des Servers glauben will - das kann das Surfen enorm beschleunigen.
Wer beispielsweise beim Vor- und Zurück-Blättern im Forum neue HTTP-Zugriffe an den Self-Server sendet, der macht m. E. etwas verkehrt - sekundengenaue Aktualität von gelesenen Postings muß nicht sein.
was genau wird also durch den Cache bezweckt,
den HTTPd die Komprimierungsarbeit abzunehmen?
Auch das (bei dynamischen Ausgaben wie der Forum-Hauptdatei).
Aber wie oben dargelegt, ist ein HTTP-Zugriff für einen "dummen" Squid sehr viel einfacher und performanter durchführbar als für einen "hochintelligenten" Apache.
Nimm Dir als Analogie eine SQL-Datenbank, welche das Statement erst in seinen internen Code übersetzen und danach ausführen muß.
Das Konzept der Host-Variablen, welche es erlauben, jeweils andere Parameterwerte für ein bereits derartig vorübersetztes Statement im SQL-Cache der Datenbank anzugeben, ist genau so ein Tuning-Mechanismus: Die Vor-Übersetzung muß nur ein einziges Mal gemacht werden, die eigentliche Ausführung der Query aber immer wieder.
Die Rationalisierung der Komprimierung inklusive
Caching würde ich naiverweise im
Zuständigkeitsbereich des Apaches ansiedeln.
Würdest Du also Deinen Abteilungsleiter Deinen Job erledigen lassen? ;-)
(Ende von Teil 1)
Viele Grüße
Michael