Einsatz eines Proxy/2. Webservers für statische Inhalte

[andreask2]

Hallo!

Ich überlege mir gerade, die statischen Inhalte einer webbasierten Software die auf einem Root-Server läuft, von den dynamischen Seiten zu trennen. Dynamisch heißt in meinem Fall mod_php. Zur Zeit läuft das alles noch über einen Apache-Server (1.3) mit allen benötigten Modulen. Das funktioniert soweit auch wunderbar, nur erfolgen doch die meisten Zugriffe - trotz entsprechender Caching-Header... immer noch auf statische Inhalte wie Bilder, Javascripte, CSS, und anderes. Der Nachteil daran ist jetzt, dass mit dieser Konfiguration unter etwas Last sehr schnell der ganzen RAM aufgebraucht wird, wenn immer mehr riesige Apache-Prozesse "geforkt" werden.

Ein weiteres Problem, bei persistenten DB-Verbindungen werden evtl. Verbindungen von Prozessen belegt, die diese Verbindung gar nicht verwenden...

Was noch dazu kommt, dass persistente HTTP-Verbindungen zwar bei statischen Inhalten viel Sinn machen, bei dynamischen Seiten allerdings Resourcen unnnötig blockieren.

Die optimale Größe der Prozesse ist stark von deren Aufgabe abhängig, wenn ein PHP-Script geparst und interpretiert wird, eine Verbindung zur DB2-DB herstellt, ohne Ende Abfragen dahin schickt und auswertet, am Ende noch die Ausgabe komprimiert wird, ist das ein ganz anderer Aufwand als einfach eine Bilddatei zu laden und an den Client zu schicken, oder möglicherweise auch nur einen Header. Das spiegelt sich unter anderem in den notwendigen Modulen wider.

Also könnte man ja vielleicht mal dran denken die statischen Inhalte auszulagern. Es kann ja nicht sein dass für ein 1-pixel gif immer so ein riesen Apache-Prozess benötigt wird.

Ich überlege zwischen 2 Varianten:

1. Verwendung eines 2. Apachen

Der 1. Apache hört port 80 ab, und kümmert sich erstmal nur um statische Inhalte. Requests an dynamische Inhalte werden an den 2. Apachen per mod_proxy und mod_rewrite weitergereicht.
Beide Apachen werden dann für den jeweiligen Anwendungsfall optimiert.

2. Verwendung einies Squid-Cache als reverse-proxy

Der Squid wäre wieder unter Port 80 erreichbar, und soll nach Möglichkeit statische Inhalte cachen. Der Vorteil ist, das der Squid hierfür sicher besser optimiert ist als die "eierlegende Wollmilchsau" Apache. Z.B. halte ich es für sehr sinnvoll statische Inhalte im RAM zu halten, was der Squid ohne Probleme machen sollte, der Apache erst seit neueren Versionen und möglicherweise noch nicht so zuverlässig.

Was haltet Ihr von den beiden Varianten? Was würdet Ihr empfehlen? Kennt Ihr evtl. gute Links zu den Themen? Vor allem zu Squid als Reverse-Proxy finde ich leider doch recht wenige gute Infos.


Viele Grüße,
Andreas

[andreask2]

ach ja, was ich vergaß - die Kommunikation zu den Clients erfolgt komplett per SSL verschlüsselt, das heißt der Apache/Squid muss in jedem Fall SSL verwenden - somit machen persistente Verbinungen natürlich noch viel mehr Sinn!

[dodolin]

Das Problem mit SSL ist, dass eigentlich alle Proxies und Clients sämtliche Inhalte nicht cachen.
HTTP ist nie persistent, ich weiß nicht, was das Wort in diesem Zusammenhang zu suchen hat. HTTP ist ein statusloses Protokoll.
Ich würde an deiner Stelle lieber darüber nachdenken, die statischen Inhalte auf einen 2. physikalischen Server auszulagern.

[andreask2]

Hallo!

Sorry, ich meinte nicht persistente HTTP Verbindungen, sondern TCP (keep alive), was sich ja über HTTP festlegen lässt.

Bei SSL wird _gundsätzlich_ nicht gecached? Das wusste ich nicht. Hm. Hmmm. Dann kann ich meine ganzen "Expire-geschichten" ja in die Tonne kloppen ;-)

Aber egal, das ändert ja nicht _so_ viel am Thema. Auf jeden Fall würde meine erste Variante funktionieren, weil hier ja der 1. Webserver selber auf die statischen Inhalte zugreift und selbige aussliefert. Wie das bei einem Reverse-Proxy Cache in Zusammenhang mit SSL ist weiß ich nicht, aber wenn der Squid in dem Fall nicht cachen kann, käme diese Variante eh nicht in Frage, denn dann bringt der Squid ja keine Vorteile mehr mit.
Bedenkt aber dass es sich hier um einen transparenten, also für den User nicht sichtbaren proxy handelt, der sich zudem noch auf demselben Server befindet, zumindest vorerst.

Hm, ich werd mich mal auf die Suche begeben wie das mit Squid und SSL aussieht, wenn jemand nen guten Link kennt kann er den gerne posten ;-)

Naja, und 2. physikalischer Server ist zwar ein gute Idee, aber zur Zeit soll es eben erstmal auf einem laufen, und dazu bräuchte ich dann auch ein weiteres SSl-Protokoll. Mal sehen irgendwann wird das sicher so gelöst, aber ebe nicht im Augenblick, und auch in dem Fall lässt sich das ja mittels Cache/Proxy nach außen transparent lösen.


Grüße
Andreas

[dodolin]

Bei SSL wird _gundsätzlich_ nicht gecached?

Per Default vermutlich, ja. Ich sagte nicht, dass es unmöglich ist, man kann einen Squid sicher dazu vergewaltigen, dass er es doch tut. ;)

SSL heißt für gewöhnlich, dass der Content als vertraulich eingestuft wird, insofern macht es keinen Sinn, diesen zu Cachen, da kaum ein 2. User nochmal den gleichen Inhalt haben will.

Wie wäre es, z.B. die Bilder ohne SSL anzubieten? Oder sind die auch vertraulich?

[andreask2]

Ja, es geht ja gerade um diese Dinge wie Grafiken (Design...), css und js. Das ist nicht wirklich vertraulich, wird aber viel eingesetzt.

[dodolin]

SSL kostet BTW auch noch zusätzliche CPU-Power. Insofern würde ich mir mal in Ruhe überlegen, welche Inhalte auf SSL verzichten können, und diese dann ganz regulär, z.b. von einem separaten vhost aus anzubieten und dann mod_expires sinnvoll einzusetzen.

[oxygen]

Ja, es geht ja gerade um diese Dinge wie Grafiken (Design...), css und js. Das ist nicht wirklich vertraulich, wird aber viel eingesetzt.

Laufen die denn zurzeit über SSL? falls ja würde ich das mal schleunigst ändern. Es ist ja kein Problem die Adressen absolut mit http statt https anzugeben.

[andreask2]

Doch, die Bowser fragen nach ob die Seite angezeigt werden soll weil die Seite unsichere Elemente enthält. Auch wenn das absolut in Ordnung ist, praktisch verschreckt das die Anwender die in jedem Fall stark drauf vertrauen dass das ganze sehr sicher ist. Wie gesagt - technisch gesehen habt ihr Recht, aber praktisch ist das nicht schön und ist indiskutabel.
Und außerdem - wenn die SSL-Verbindung einmal steht, und dank keep-alive auch länger(über mehrere Requests) bestehen bleibt, ist das mit der Rechenlast auch nicht mehr so wild, da dann AFAIK nur noch eine symmetrische Verschlüsselung angewendet wird, was erheblich schneller geht als die Asymetrische bei jedem Verbindungsaufbau.

Außerdem mache ich mir eher Sorgen um den RAM als die CPU.

Grüße
Andreas