Michael Schröpl: Das Mozilla-Wunder - und seine Erklärung

Beitrag lesen

Hi Andreas,

http://webalizer.teamone.de/selfforum/usage_200210.htm#TOPAGENTS
Also irgendwas hat sich diesen Monat geändert,

in der Tat. :-)))

Das, was alle Besucher unter den bekannten DNS-Namen auf Port 80 ansprechen, ist seit diesem Monat kein Apache-Webserver mehr.

... (Verblüfftes Schweigen. "Was denn sonst?")

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.

Dies ist insgesamt auch das Ergebnis einer Kooperation mit den aktuellen mod_gzip-Entwicklern - denn mod_gzip mußte dazu allen Proxies korrekte "Vary:"-Header mit der Angabe der Namen sämtlicher bei der Verhandlung relevanter HTTP-Header liefern, damit Squid 2.5 begreift, wovon es abhängt, welchen Content wer bekommen darf.
Das macht mod_gzip 1.3.26.1a nun schon recht ordentlich - es sendet tendentiell eher etwas zuviel an "Vary:"-Angaben, weil es in einigen Fällen noch nicht erkennt, daß die Verhandlung immer zuungunsten der Komprimierung ausgehen wird, aber das ist im Schnitt nicht schlimm.

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.

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.

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

Und das Ergebnis der Änderung ist insbesondere, daß die Webalizer-Zahlen nun an Aussagefähigkeit stark eingebrochen sind.
Es hängt beispielsweise von der Art des Surfens ab (aktives "reload" oder nur Klicken auf Links), ob ein Anwender bei seinem Zugriff ein "Cache-Control: no-cache" mit sendet und dadurch den Squid dazu zwingt, die Anforderung zum Apache durchzuleiten, oder ob er das nicht tut und mit dem Content des Proxy auch zufrieden ist.
Und der konkrete Effekt kann auch von den Browser-Einstellungen, eventuell sogar von browserspezifischem Verhalten abhängen.
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 ...

In jedem Fall können wir die Zugriffs-Statistik des Webalizers für das Apache-Log jetzt den Hasen geben.

Viele Grüße
      Michael

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