nicht angemeldet
Hallo, Michael,
Es gibt seit kurzem eine stabile Version von Squid 2.5.
Und der kann - erstmals - die Ergebnisse von Content Negotiation koexistenzfähig cachen.
Er begreift also nicht nur, daß er einigen Browsern die via mod_gzip komprimierte Version eines URL ausliefern darf und anderen eine unkomprimierte Version ausliefern muß, er kann jetzt _beide_ Versionen _nebeneinander_ in seinem Cache halten und korrekt an die jeweiligen Browser verteilen.
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? Bzw. tut er das? 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?
Wieso werden die statischen Seiten eigentlich erst mit mod_gzip komprimiert und liegen nicht schon komprimiert im Dateisystem, oder tun sie das?
Weil nun also Squid 2.5 nicht nur die bekannten Probleme des Caching komprimierter Seiten im Griff zu haben scheint, und gleichzeitig mod_gzip die Tatsache, Verhandlungsergebnisse auszuliefern, nun nicht mehr verschweigt (wie noch in Version 1.3.19.1a), arbeiten beide nun so gut zusammen, daß Christian den komprimierenden Apache-Server hinter einem Caching Proxy 'verstecken' konnte.
Das hat man an den Fehlermeldungen gemerkt. ;)
Was keinem der bisherigen Diskussionsteilnehmer aufgefallen ist: Schaut Euch mal die Zugriffszahlen pro Tag an!
Im September waren das für selfhtml.teamone.de gemäß http://webalizer.teamone.de/selfhtml/ im Schnitt deutlich über 300.000 URL-Anforderungen pro Tag - seit Oktober sind das nur noch 35.000 Stück!
Wenn man von einem gleichbleibenden Traffic ausgeht, dann werden etwa 90% der bisherigen Zugriffe nun also gar nicht mehr zum Apache-Server durchgeleitet, sondern bereits aus dem Proxy-Cache bedient.
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. 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... was genau wird also durch den Cache bezweckt, den HTTPd die Komprimierungsarbeit abzunehmen? Die Rationalisierung der Komprimierung inklusive Caching würde ich naiverweise im Zuständigkeitsbereich des Apaches ansiedeln.
Welches Verzeichnis ist eigentlich mit 'SRC' gemeint: http://webalizer.teamone.de/selfhtml/usage_200210.htm#TOPURLS? Sind das die Stylesheets, Favicons etc.? Selbige Anfragen brauchen theoretisch nie den Apache belasten.
Bei http://webalizer.teamone.de/selfforum/, der Statistik für das vollständig auf dynamischen Seiten basierende Forum, kann man dagegen 'nur' einen Rückgang der Zugriffe pro Tag von etwa 40% erkennen - die vielen kleinen Markerungs-Bildchen und das bereits statische Forum-Archiv lassen sich durchaus cachen, das Forum selbst derzeit noch so gut wie nicht.
Jegliche Anfragen an das Archiv könnte man auch in jedem Fall vom Squid bearbeiten lassen, wenn sie einmal gecachet sind. Okay, die machen auch jetzt schon nur einen Bruchteil aller durchgereichten Anfragen aus.
Auch hier gibt es allerdings Überlegungen, beispielsweise die Forums-Hauptdatei mit eine Aufbewahrunsgfrist von einigen Sekunden in den Proxy-Cache zu legen, um den Server zu entlasten. Denn eine sekundengenau aktuelle Forums-Hauptdatei ist für den Betrieb des Forums selbst gar nicht sooo wichtig.
Squid würde also nur alle X Sekunden eine Anfrage an den Apache durchreichen und derweil mehrere komprimierte und unkomprimierte Versionen zwischenspeichern? Das funktioniert so ohne weiteres bzw. lässt sich individuell für jede URL einstellen?
Wie funktioniert eigentlich das Interface zwischen Squid und Apache - das ist doch eine gewöhnliche HTTP-Kommunikation, ist das nicht etwas suboptimal, dass zwei Prozesse miteinander über ein Klartextprotokoll kommunizieren... ich habe dahingehend wenig Wissen, aber es erscheint mir seltsam. Deshalb meine Idee, die Funktionen des Squids besser im Apache anzusiedeln, wenn dies denn möglich wäre.
Bei anderen trafficintensiven Seiten kenne ich nur, dass statische Inhalte immer über einen kleinen HTTPd (thttpd usw.) ausgeliefert werden, welcher im Vergleich zu einem klobigen Apache *enorm* ökonomischer mit den Resourccen umgeht, wenn die Anfragen pro Zeiteinheit in die Höhe schnellen.
Eigentlich ist das nämlich gar keine gute Nachricht, daß Mozilla jetzt plötzlich auf Platz 1 steht - denn es spricht entweder gegen die Surf-Gewohnheiten seiner Anwender oder gegen die Art und Weise, wie Mozilla mit HTTP umgeht und mit dem Squid zusammen arbeitet ...
Das lohnt sich detailliert zu untersuchen, finde ich.
In jedem Fall können wir die Zugriffs-Statistik des Webalizers für das Apache-Log jetzt den Hasen geben.
Im Bezug auf die Browserverwendung schon, allgemein wertet Webalizer aber mehr aus, was für die Analyse der durchgereichten Anfragen hilfreich sein könnte.
P.S.: Die gute Nachricht ist: Der Webalizer kann 'natürlich' auch das Logfile-Format des Squid lesen ... es müßte 'nur' jemand den Betriebsablauf des Servers entsprechend umbauen ...
Theoretisch könnte man das Logging des Apaches auf ein Minimum herunterfahren, denn was bringt es, wenn er in aller Ausführlichkeit loggt, was der Squid sowieso schon verzeichnet hat...
Grüße,
Mathias
P.S. Ich wollte nicht besserwisserisch wirken (ich weiß es nicht besser, das dürfte klar sein), ich bin lediglich daran interessiert und möchte mein Wissen erweitern.