webalizer: Mozilla 5.0 auf #1 ?

[Andreas Korthaus]

Hallo!

http://webalizer.teamone.de/selfforum/usage_200210.htm#TOPAGENTS

Also irgendwas hat sich diesen Monat geändert,
mozilla 5.0 auf Platz 1,
WebZIP/5.0 auf Platz 2,
MSIE 4.0 auf Platz 3

das kann doch nicht wirklich sein, und wenn ich nicht ganz falsch gerechen habe fehlen da auch ein paar %. Vor allem MSIE 4 vor 5 und 6, das ist doch recht seltsam, oder? Habt Ihr eigentlich auch irgendwo die User-Agents stehen? Am besten ein Ranking der User-Agents?

Grüße
Andreas

PS: Wann kommt eigentlich AOL mit gecko?

[MudGuard]

Hi,

http://webalizer.teamone.de/selfforum/usage_200210.htm#TOPAGENTS

Also irgendwas hat sich diesen Monat geändert,
mozilla 5.0 auf Platz 1,
WebZIP/5.0 auf Platz 2,
MSIE 4.0 auf Platz 3

das kann doch nicht wirklich sein, und wenn ich nicht ganz falsch gerechen habe fehlen da auch ein paar %. Vor allem MSIE 4 vor 5 und 6, das ist doch recht seltsam, oder? Habt Ihr eigentlich auch irgendwo die User-Agents stehen? Am besten ein Ranking der User-Agents?

Warum sollte das nicht stimmen?
Hier im Forum ist der Mozilla-Anteil sehr hoch.
Weil hier eben viele Leute sind, die einen richtigen Browser haben wollen.

Und klar fehlen da noch ein paar Prozent. Es steht doch auch drüber: Top 15 von 302 ...
Die fehlenden 6.01% (wenn ich mich nicht verrechnet habe) verteilen sich auf die 287 dort nicht aufgeführten Programme.

Andreas

[Orlando]

Hi Andreas,

http://webalizer.teamone.de/selfforum/usage_200210.htm#TOPAGENTS

Habt Ihr eigentlich auch irgendwo die User-Agents stehen? Am besten ein Ranking der User-Agents?

ja, direkt darunter ist ein roter Link...

http://webalizer.teamone.de/selfforum/agent_200210.htm

LG Orlando

[Sven Rautenberg]

Moin!

ja, direkt darunter ist ein roter Link...

http://webalizer.teamone.de/selfforum/agent_200210.htm

Genau, die dort angegebenen Prozentzahlen addieren sich zu 99,13% - der fehlende Rest zu 100% dürfte in den restlichen knapp zwei Drittel der Zeilen liegen, die mit 0,00% angegeben sind - Rundungsfehler.

Die Statistik für September ist aber "ganz normal" - obwohl IE6.0 nur 35% Anteil hat, IE 5.5 17%, und Mozilla/5.0 knapp geschlagen ebenfalls 17%.

- Sven Rautenberg

[Andreas Korthaus]

HallO!

Genau, die dort angegebenen Prozentzahlen addieren sich zu 99,13% - der fehlende Rest zu 100% dÃrfte in den restlichen knapp zwei Drittel der Zeilen liegen, die mit 0,00% angegeben sind - Rundungsfehler.

Die Statistik fÃr September ist aber "ganz normal" - obwohl IE6.0 nur 35% Anteil hat, IE 5.5 17%, und Mozilla/5.0 knapp geschlagen ebenfalls 17%.

OK, hast Recht, aber warum hat der IE 6 von heute auf morgen nur noch die HÃlfte? Und warum haben so viele Leute Ihre Vorliebe fÃr den IE 4 wiedergefunden? Vor allem - wer hat den noch? So ein Anstieg um mal eben  Ãber 3000 %, das hat man nicht alle Tage.
Wenn Ihr mich fragt ist das ein Fehler von Webalizer und die 15% sind dem IE 6 zuzuschreiben. Vielleicht wurde durch das Service-Pack was am User-Agent verÃndert?

Und auch der komische webzip Spider, ein Anstieg von 0% auf 17%, das ist doch nicht normal!

GrÃÃe
Andreas

[molily]

Hallo, Roland,

http://webalizer.teamone.de/selfforum/agent_200210.htm

Bist du derjenige mit Opera 7.0? :) Gib's zu, du kannst es nicht abwarten und hast dich bei Opera Software eingehackt und einen Alpha Build geklaut! ;)

Dennoch scheint mir die Statistik etwas verfälscht, sie müsste mit der Anzahl der *Besucher* mit dem jeweiligen UA in Relation gesetzt werden, nicht mit der Anzahl der Zugriffe... naja, wer behauptet schon dass die Statistik aussagekräftig sei.

Den Typ, der mit Webzip massiv Traffic verschwendet, sollte man zur Kasse bitte, angenommen er oder sie kopiert sich alle Seiten, um sie in einen Intranet zu nutzen.

Was ist eigentlich sfa_idx.txt? (Eine Datei mit allen Selfforum-Postings, schon klar.) Wird das für den SelfBrowser benötigt?

Zu hilf, meine Tastatur spinnt wieder, schnell absenden und neustarten.

Grüße,
MMATHIAIS <- so sHE ES nkorriggiert aus
;) Mathias

[Orlando]

Hi Mathias,

http://webalizer.teamone.de/selfforum/agent_200210.htm

Bist du derjenige mit Opera 7.0? :) Gib's zu, du kannst es nicht abwarten und hast dich bei Opera Software eingehackt und einen Alpha Build geklaut! ;)

tja, wieder ein ungeklärtes Rätsel :) Dabei bin ich schon extrem sauer, dass es diesmal keine richtige Beta geben wird (wäre ja auch Opera/7.0b *g*) und die Final wieder mal so lange auf sich warten lässt. In der dt. Opera-NG wurde übrigens vor kurzem wild spekuliert, weil jemand mit diesem User-Agent auf favicon.ico zugegriffen hatte. Konspiration! ;)

Dennoch scheint mir die Statistik etwas verfälscht, sie müsste mit der Anzahl der *Besucher* mit dem jeweiligen UA in Relation gesetzt werden, nicht mit der Anzahl der Zugriffe... naja, wer behauptet schon dass die Statistik aussagekräftig sei.

Richtig, da fallen die Stammgäste natürlich mehr in's Gewicht.

Was ist eigentlich sfa_idx.txt? (Eine Datei mit allen Selfforum-Postings, schon klar.) Wird das für den SelfBrowser benötigt?

<linksetzer>
 </archiv/2000_1/t10624.htm#a53582>
 http://www.atomic-eggs.com/selfspezial/sstattop.php#a4
</linksetzer>

BTW, http://my.opera.com/forums/showthread.php?s=&threadid=4312

LG Orlando

[Cheatah]

Hi,

Dennoch scheint mir die Statistik etwas verfälscht, sie müsste mit der Anzahl der *Besucher* mit dem jeweiligen UA in Relation gesetzt werden, nicht mit der Anzahl der Zugriffe...

was ist ein "Besucher"? HTTP kennt für derartige Begriffe keine Definition.

naja, wer behauptet schon dass die Statistik aussagekräftig sei.

Du hast gerade einen der Gründe erkannt, weshalb solche Statistiken *nichts* aussagen. Okay, wenn es der einzige Grund wäre, müsste ich "nichts über andere Sites" schreiben.

Zu hilf, meine Tastatur spinnt wieder, schnell absenden und neustarten.

Du solltest Dich beim Hersteller beschweren. Spinnende Tastaturen sind nun wirklich kein Zustand - ständig muss man den Arbeitsplatz von Spinnweben befreien, das geht doch nicht.

Cheatah ;-)

[molily]

Hallo, Cheatah,

Dennoch scheint mir die Statistik etwas verfälscht, sie müsste mit der Anzahl der *Besucher* mit dem jeweiligen UA in Relation gesetzt werden, nicht mit der Anzahl der Zugriffe...

was ist ein "Besucher"? HTTP kennt für derartige Begriffe keine Definition.

Genaugenommen hast du recht, aber dann könnte man jegliche Zugriffsstatistiken vergessen. Indem man dies selbst definiert, was "ein Besucher" ist, kann man sich durchaus Statistiken konstruieren (sic). Außerdem gibt es Session-Tracking über GET oder Cookies usw.
Dass eine Statistik mit einer großen[tm] untersuchten Grundgesamtheit keine repräsentativen Aussagen auf die Browserbenutzung ermöglich, glaube ich dir jedoch nicht. Auch sind die Verfahren zur Bestimmung von "Besuchern" für eine Näherungslösung imho hilfreich - es geht auch nur um den Vergleich (mehr/weniger Besucher). Denn wenn die Messmethode einheitlich ist und gegen Manipulationen und besondere Phänomene sicher ist (soweit möglich), kann man recht genau feststellen, ob eine Entwicklung stattgefunden hat.

Ich unterhalte Seiten mit einer breiten Zielgruppe, Seiten mit einer technisch interessierten und Seiten mit einer an Unterhaltung interessierten Zielgruppe. Ich kann feststellen, dass unter den Zielgruppen eine unterschiedliche Browsernutzung vorherrscht. Behauptest du, das ich mir das nur einbilde, weil sowieso jeder zweite UA-Header fälscht oder Anon-Proxies benutzt? Überhaupt könntest du behaupten, dass der IE in Wirklichkeit gar nicht der meistgenutzte Browser ist... also wirklich, irgendwo hört der Skeptizismus auf.

Ich denke einmal, die IVW und ähnliche Organisationen haben durchaus Kenntnis von den Problemen der Bestimmung von "Besuchern" und aufgrund meiner Naivität erlaube ich mir darüber kein Urteil, nur weil HTTP ein zustandsloses Protokoll ist. Die haben durchaus ausgeklügelte Messmethoden. Dennoch behauptet niemand, dass sich dadurch hundertprozentig genaue Ergebnisse berechnen lassen, ein Vergleich ist m.E. trotzdem möglich. Wenn man Session-Cookies einsetzt, lassen sich Werte wie page impressions per visit berechnen.

Wo ist das Problem, wenn "ein Besucher" definiert wird und dementsprechende Untersuchungen gemacht werden? Jeder Statistiker weiß, dass dies möglicherweise wenig damit zu tun hat, wieviele unterschiedliche menschliche Individuen sich die Seite angeschaut haben - dass man das nicht herausfinden kann, sollte klar sein, aber das ist bereits die Prämisse aller statistischen Untersuchungen.
Natürlich kapieren das manche Neulinge nicht.

Was spricht außerdem dagegen, "X Besucher sind online" als "Anzahl der in den letzten Y Minuten eingegangenen Requests von unterschiedlichen IPs (Client-IPs, nicht Proxy-IPs) mit unterschiedlichen Session-Variablen und UA-Headern" zu definieren - dass eine Anzeige null Informationswert für den Besucher hat, ist bekannt, aber für den Seitenbetreiber, welcher ein herausfinden möchte, wieviele "Besucher" eine Seite innerhalb einer Zeiteinheit ansehen, ist es durchaus ausreichend.

Kurz gesagt: ich kann nicht verstehen, wieso du immer wieder darauf pochst, dass jegliche Statistiken unsinnig sind, denn die Unmöglichkeit der präzisen Messung von "Besuchern" ohne Konstruktion eines selbigen ist jedem bekannt...

naja, wer behauptet schon dass die Statistik aussagekräftig sei.

Du hast gerade einen der Gründe erkannt, weshalb solche Statistiken *nichts* aussagen.

s/nichts/wenig/. IMHO. Ich schaue durchaus in die Besucher^WZugriffsstatistik der von mir betreuten Seiten und ziehe meine Schlüsse daraus. Ich will sogar behaupten, dass ich merke, wenn die jeweilige Seite mehr "Besucher" bekommt.

Okay, wenn es der einzige Grund wäre, müsste ich "nichts über andere Sites" schreiben.

Wie meinen? Eine Statistik kann auch nur über die untersuchte Seite etwas aussagen, klar. ;) Oder was meintest du?

Zu hilf, meine Tastatur spinnt wieder, schnell absenden und neustarten.

Du solltest Dich beim Hersteller beschweren. Spinnende Tastaturen sind nun wirklich kein Zustand - ständig muss man den Arbeitsplatz von Spinnweben befreien, das geht doch nicht.

...weaving the Web. :)

Grüße,
Mathias

[xwolf]

Hi,

hmm...also wenn ich mir die Top 30 der Rechner anschaue, frag ich mich, ob hier ein paar Leute süchtig sind :)

Dazu ein Artikel und mahnendes Beispiel:
http://www.n-tv.de/3071327.html

(Obwohl? Manche wollen ja auch beim Sex oder halt in ihren glücklichen Momenten sterben....Aber ob dies auch für süchtige Internetfreaks gilt? .. uh-oh.)

Cioa,
  WOlfgang

[Michael Schröpl]

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

[molily]

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.

[Michael Schröpl]

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

[Michael Schröpl]

Hi Mathias,

... weiter im Text:

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.

Vor allem sind das die kleinen Markierungsbildchen.
Auf diese gibt es unzählige HTTP-Zugriffe von schlecht konfigurierten Browsern.
Aber auch CSS-Dateien gehören in diesen Bereich - glücklicherweise nur etwa eine pro HTML-Seite.
(Wenn ein M$IE einen Fehler in seiner lokalen Cache-Struktur hat, dann kann es Dir passieren, daß er bei der Anforderung der Forum-Hauptdatei das Bildchen vor _jeder_ Posting-Zeile pro Verwendung _einzeln_ anfordert - also weit über 100 HTTP-Requests für dieselbe Ressource abfeuert ... Browser-Cache löschen und ggf. den Rechner booten hat in solchen Fällen schon geholfen - sofern der Anwender sich eines solchen Problems überhaupt bewußt ist!)

Genau dieses Zeug läßt sich in der Tat am besten vom Squid ausliefern - es sei denn, ein Browser _befiehlt_ dem Squid, sie von der Original-Quelle zu holen.
Wenn der Squid sich HTTP-konform verhalten will, muß er diesem Befehl gehorchen.

Es gibt allerdings diverse Squid-Konfigurations-Direktiven, die gegen die Anforderungen von HTTP _bewußt_ verstoßen - wenn man (wie im vorliegenden Falle) mehr über das Szenario weiß, als dies normalerweise bei HTTP der Fall wäre, _kann_ man bestimmte Elemente von HTTP aktiv außer Kraft setzen.
Man muß dann halt _sehr_ genau wissen, was man tut ... "kids, don't try this at home". ;-)

Jegliche Anfragen an das Archiv könnte man auch in
jedem Fall vom Squid bearbeiten lassen, wenn sie
einmal gecachet sind.

Wenn die Apache-Konfiguration für dieses Teil-Verzeichnis so vorgenommen wurde, daß der Apache eine Aufbewahrungsfrist von <n> Jahren (!) an den Squid sendet, dann passiert de facto auch genau dies.

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?

Ja und ja. ;-)

Die 'Einstellung' erfolgt ja im Apache bei der Erzeugung der Seite.
Und das Forum ist eine CGI-Anwendung, welche ihre HTTP-Header selbst generiert - es ist kein Problem, im Falle eines Postings eine Aufbewahrungsfrist von z. B. 5 Minuten, im Falle der Hauptdatei aber von 30 Sekunden mit zu senden. Das Forum-Skript weiß ja, ob es gerade seine Hauptdatei oder ein Posting ausliefert ...

Wie funktioniert eigentlich das Interface zwischen
Squid und Apache - das ist doch eine gewöhnliche
HTTP-Kommunikation,

Ja. Für den Apache ist der Squid ein UserAgent wie jeder andere auch.
Genauer gesagt: Der Apache sieht den Request so, wie der Squid ihn auch gesehen hat - mit ggf. minimalen Änderungen.
Ein "braver" Proxy fügt beispielsweise einen "Via:"-Header dazu, um dem Apache-Administrator im Falle eines Problems einen Hinweis zu liefern, daß der Request von ihm kam und nicht direkt von einem Browser.

ist das nicht etwas suboptimal, dass zwei Prozesse
miteinander über ein Klartextprotokoll
kommunizieren...

Der Apache spricht HTTP. Jeder Client muß ihn also via HTTP ansprechen. Es gibt aus Sicht des Apache keine "bevorzugten" Clients.
Der Trick besteht eben darin, daß so wenig wie möglich solcher Kommunikationen notwendig sein sollten.

Und bedenke auch: Es ist technisch durchaus möglich, am Squid vorbei direkt auf den Apache zuzugreifen (sofern der Administrator das erlaubt).
Wenn beispielsweise ein URL uncachebare Daten liefert, aber sehr oft angesprochen werden muß, dann _kann_ dieser URL über den Apache selbst (derzeit auf Port 81) adressiert werden. Wo der Squid nichts nützt, sondern nur behindert, da muß man ihn nicht einsetzen.

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.

Ja, das ist natürlich auch möglich.

Apache enthält ein Modul namens mod_proxy - der Apache kann durchaus selbst auch als Caching Proxy arbeiten. Ich selbst verwende mod_proxy beispielsweise dazu, um Seiten von anderen Webservern damit in den URL-Baum meines Apache einzublenden, und die aus mod_proxy heraus kommenden Seiten kann der Apache dann sogar mit Hilfe von mod_gzip komprimieren - selbst wenn der Original-Webserver das nicht gekommt hätte ... ich mache so etwas beispielsweise mit einem M$-IIS 4.0, vor den ich einen Apache mit mod_proxy und mod_gzip gestellt habe. Der Besucher merkt nicht, daß Teile meines URL space auf anderen Servern liegen.

Aber mod_proxy ist weder so schnell noch so mächtig wie der (nagelneue) Squid 2.5, denn mod_proxy hält seinen Cache auf der Festplatte, während Squid ihn im Hauptspeicher hält ... in Sachen Performance ist mod_proxy zweifellos nicht die Speerspitze der verfügbaren Technologie. (Das ist auch nicht seine Zielsetzung, denke ich.)

Eine andere Möglichkeit wäre die Verwendung des Apache-Moduls mod_mmap_static, welches eine Listen von (statisch konfigurierbaren) URLs im Hauptspeicher halten könnte.
Nachteile:
a) Diese Liste muß _manuell_ gepflegt werden
b) Das Modul ist laut Apache Group "experimental".
Ich vermute zudem, daß der Apache-URL-Mechanismus nicht komplett umgangen wird.

Es gibt also durchaus die Idee, alles aus einer Hand zu liefern (auch wenn sie bisher nicht zuende gedacht wurde).
Aber Squid hat sich auf sein Gebiet spezialisiert und ist dort nicht aus Versehen Marktführer.

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.

Genau so ein schlanker HTTP-daemon ist der Squid eben. ;-)

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

Aber wenn gut 90% aller Requests nicht mehr beim Apache ankommen, sondern nur noch willkürliche knapp 10%, wird das jede Analyse dieser rechtlichen Zugriffe stark verzerren.

wertet Webalizer aber mehr aus, was für die Analyse
der durchgereichten Anfragen hilfreich sein könnte.

Das gilt ja immer noch.

Das Squid-Log, welches der Webalizer eben auch auswerten kann, enthält nicht weniger interessante Informationen als das Apache-Log. (Im Gegenteil sogar mehr - beispielsweise Cache-Hit-Raten, Memory-Hit-Raten usw.)

Der 'browser watch' des Self-Portals wird sich halt künftig auf das Squid-Log stützen müssen.

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

Was das access_log angeht (welches der Webalizer bisher auswertet), stimme ich dem zu.
Allerdings ist der Aufwand für das Logging natürlich mit sinkenden Zugriffszahlen ohnehin geringer als bei 'voller Leistung' des Apache. Dennoch ist die Idee natürlich richtig.

Das error_log wird weiterhin gebraucht, um Fehler bzw. Probleme im Apache-Betrieb zu finden.
Dort stehen beispielsweise Meldungen über den von Apache dynamisch verwalteten Pool an Kind-Prozessen, welcher bei Last-Schwankungen dynamisch angepaßt wird, und ähnliche Informationen. Und natürlich Zugriffe, die mit HTTP-Status-Werten wie 404 oder 500 endeten - ein vorgeschalteter Cache kann in diesen Fällen nichts tun.

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.

Wie Du oben gesehen hast, haben wir uns teilweise exakt dieselben Fragen gestellt.

Viele Grüße
      Michael