nicht angemeldet
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