[Technik] mod_proxy und Caching (Hintergrund und Konfigurationsvorschlag)

[Michael Hierweck]

Hallo allerseits,

diverse Webapplikationen können davon profitieren, wenn man einen Cache
vorschaltet, der statische Komponenten oder auf unter gewissen Umständen
dynamisch erzeugte Inhalte zwischenspeichert und ausliefert.

Bei einer geschickten Konfiguration der Webanwendung können so,
unabhängig von der eingesetzten Sprache, Aufrufe der dynamischen
Komponenten (PHP, Perl, Python, CGI etc.) vermieden werden.



[Am Beispiel von Zope, insbesondere im im Zusammenhang mit seiner
"Killerapplikation" Plone, wird die besonders deutlich:

Zope-Websites liefern im Regelfall alle Inhalte, also auch statische
Grafiken, Stylesheets, Javascripts usw., über den Applikationsserver
aus. D.h. für jedes angeforderte Objekt wird Zope angesprochen, Rechte
geprüft, das Objekt aus der Datenbank geholt und ausgeliefert. Dies sind
bei herkömmlichen Plone-basierende Websites dutzende. Im Regelfall würde
es jedoch genügen, die HTML-Seite dynamisch auszuliefern. (Selbst das
wäre in Einzelfällen nicht notwendig.) Plone und Zope bieten
hervorragende Möglichkeiten einen Cache/Proxy mit Cache Control Headern
zu versorgen und sogar Möglichkeiten gecachte Inhalte bei Änderung
zumindest aus Squid als eingesetztem Reverse Proxy zu entfernen.

Anders ausgedrückt: ohne vorgeschalteten Cache erzeugt jede Page
Impression dutzende IO-, aber vor allem CPU-intensive Operationen.

Am Beispiel einer von mir betreuten Website wird dies in Zahlen
deutlich: Wir messen rund 20.000 Seitenabrufe am Tag, ein Seitenabruf
umfasst etwas mehr als 70 zu ladende Elemente. Damit wird jener
Zope-Server mit rund 1.500.000 Requests beschäftigt. Wenn man allein die
statischen Komponenten, wie dekorative Grafiken, cachen könnte, würde
man gut 1.200.0000 "dynamische" Requests einsparen, quasi in
Statik-Web-Requests umwandeln.]



Die Zope-Maintainer würden sich daher freuen, wenn wir
möglichst bald zur Proxy-Konfiguration, etwa nach folgendem Schema
zurückkommen könnten und damit Auslieferung von Zope- und Plone-Websites
nicht nur erheblich beschleunigt werden könnte, sondern auch deutlich
CPU- und IO-Ressourcen eingespart werden könnten. (Nach Meinung der
Plone-Experten ist der Einsatz von Plone ohne Reverse-Proxy und Cache
außer bei schwachfrequentierten Seiten unvernünftig. Allerdings geht man
in der Community (stillschweigend) recht durchgängig von dedizierten
Servern oder Root-Servern aus.)



So könnte die Konfiguration nach unserer Ansicht (Danke an Veit) aussehen:

LoadModule proxy_module /usr/lib/apache/1.3/libproxy.so
...
LoadModule apache_ssl_module /usr/lib/apache/1.3/libssl.so
...
<IfModule mod_proxy.c>

    ProxyRequests Off
    # Aus Sicherheitsgründen wird die globale Proxyfunktion
    # ausgeschaltet. Proxy soll explizit in der Weiterleitung
    # verwendet werden.

    ProxyVia On

    CacheRoot "/var/cache/apache"
    CacheSize 1000
    # Das ist hostabhängig und von mir nicht wirklich zu beurteilen.

    CacheGcInterval 1
    CacheMaxExpire 24
    CacheLastModifiedFactor 0.1
    CacheDefaultExpire 1
</IfModule>

Für SSL sollte ein anderer CacheRoot verwendet werden:

CacheRoot "/var/cache/apache-ssl"



Bekannte Probleme:

Der Einsatz mod_proxy bei Apache 1.3, wie er auch für laut HS-Doku für
Tomcat empfohlen wird, hat noch immer das "Leerzeichen im URL"-Problem,
d.h. mod_proxy setzt eingehende "%20" im URL auf " " um. Wir haben
zumindest für Plone jedoch Workarounds gefunden, so dass wir mod_proxy
zumindest als Option anbieten können. (Das Problem tritt mit mod_proxy
unabhängig vom eingeschalteten Cache auf. Das Problem trat in Tests mit
Apache 2.2 nicht mehr auf.)

Wir hatten vor längerer Zeit Caching via mod_proxy testweise im Einsatz.
Damals war uns das vorgenannte Problem jedoch nicht bekannt,
andererseits hatte ein Genosse Probleme mit beschädigten Grafiken, die
mit langer Gültigkeitsdauer gecacht worden waren. Daher wurde das
Caching damals wieder abgeschaltet. Evtl. könnte man daher in der
Anfangsphase (oder dauerhaft) CacheMaxExpire auf einen kürzeren Zeitraum
setzen, z.B. von einer oder wenigen Stunden*. Das könnte die Hostmaster
von Serviceanfragen entlasten, wenn aufgrund einer Fehlkonfiguration
irrtümlich Inhalte mit langer Gültigkeitsdauer im Cache gelandet wären.



[* Das Rechenbeispiel verdeutlicht, dass die Gültigkeitsdauer
hinsichtlich Leistungsfähigkeit des Caches bei stark frequentierten
Seiten wenig relevant ist, entscheidender ist, dass es (überhaupt) einen
Cache gibt:

CacheMaxEpire 1d => ( 1x50 + 20.000x15)x dynamische Generierung
CacheMaxEpire 1h => (24x50 + 20.000x15)x dynamische Generierung

Angesichts einer Ersparnis von rund 1.200.000 Aufrufen pro Tag spielen
diese zusätzlichen 1.200 Aufrufe wohl keine Rolle.]



Wie seht ihr das?

Viele Grüße

Michael

-- 
EDV-Serviceteam Werthmann & Hierweck GbR
Annika Werthmann, Michael Hierweck
Kleyer Weg 36, 44149 Dortmund
http://www.edv-serviceteam.net