Squid Proxy Server mit Typo3

Das Caching von TYPO3 ist zwar sehr ausgereift, kann aber bei stark besuchten Websites an seine Grenzen stoßen. Durch den Einsatz eines Proxy-Servers können wertvolle Ressourcen des Webservers unter anderem für Lastspitzen aufgespart werden.

Ein Proxy ist ein Server, der als Bindeglied zur Kommunikation zwischen dem Nutzer mit dem Webserver eingesetzt wird. Er speichert die Webseiten für eine bestimmte Zeit zwischen und liefert sie an den Nutzer. Dient der Server ausschließlich der Speicherung von Webseiten, spricht man von einem „Acceleration Proxy Server“. Auch beim Einsatz von TYPO3 macht ein Proxy-Server unter Umständen Sinn. Zwar verfügt TYPO3 seit Version 4.0 über ein sehr gutes Caching, aber bei jeder Anfrage auf eine TYPO3-Webseite muss eine PHP-Instanz gestartet werden, die eine zusätzliche Abfrage an die Datenbank richtet. Bei stark frequentierten Webseiten wird folglich die Anzahl der gleichzeitig möglichen Zugriffe durch die begrenzte Leistung der Webserver und die maximale Anzahl gleichzeitiger Datenbankverbindungen limitiert. Ein Proxy-Server wird also benötigt, um auch in Spitzenzeiten die Anzahl der Zugriffe auf die Datenbank zu minimieren. Die bereits erzeugten Seiten werden für eine festgelegte Zeit zwischengespeichert und direkt ausliefert.

In dieser Anleitung wird ein Setup beschrieben, bei dem sich der Proxy- und der Webserver auf demselben Rechner befinden. Das Setup findet überall dort Verwendung, wo nur ein Rechner zur Verfügung steht (z. B.: Vserver oder Root-Server). Die Konfiguration kann aber mit kleinen Änderungen an größere Netzwerke angepasst werden.

In jeder aktuellen Linux-Distribution ist ein „Squid Proxy-Server“  enthalten. Nach der Installation sollte die Datei „squid.conf“ im Verzeichnis „/etc/squid“ vorhanden sein. Derzeit gibt es zwei Versionen, die für den produktiven Einsatz geeignet sind: 2.5.x oder 2.6.x. Zwischen diesen beiden Versionen gibt es Unterschiede in der Konfiguration als „Acceleration Proxy Server“ – auf beide Versionen wird in diesem Howto Rücksicht genommen. Hier aber zunächst die Einstellungen, die bei beiden Versionen der Datei funktionieren und angewendet werden sollten:

Mit „icp_port 0“ wird die Kommunikation mit anderen Caches im Netzwerk deaktiviert und mit „cache_replacement_policy“ vereinbart, wie der Cache wieder freigegeben werden soll. „cache_mem“ gibt die Größe des Arbeitsspeichers an, der für flüchtige Cache-Objekte genutzt werden kann. „cache_dir“ gibt den Ort, die Größe und die Struktur des Caches auf der Festplatte an. Für Version 2.5.x müssen folgende Einstellungen hinzugefügt oder angepasst werden:

Der „http_port“ gibt den Host und Port an, an dem der Squid „hören“ soll und „httpd_accel_port“ sowie „httpd_accel_host“ geben den Port/Host an, wo der Webserver „hört“. Bei Version 2.6.x sollte die Konfiguration wie folgt aussehen:

Wie in der Version 2.5.x ist der Parameter „http_port“ der Port, auf dem der Squid „hört“. Mit „vport“ wird der Port zum Webserver angegeben und „defaultsite“ die IP des Webservers. Mit „cache_peer“ wird dem Squid gesagt, wo er andere Squid-Caches findet und wie er mit ihnen umgehen soll. So lassen sich Cache-Hierarchien aufbauen (sodass zum Beispiel jeder Webserver einen eigenen kleinen Squid-Cache besitzt), die aber alle den großen firmenweiten Squid-Cache als parent haben. Auf diese Weise wird
zunächst im kleinen Cache angefragt und bei einem Cache-Miss der parent. In diesem Beispiel geben wir aber bei „cache_peer“ nur den Webserver an, auf dem die Inhalte zu finden sind. Seit Version 2.6 ist es möglich, ein eigenes Logformat zu definieren und die Logs mit ACL's zum Beispiel für jede Domain aufzuteilen:

Bei dieser Konfiguration werden die Logs im combined Format für die Domain www.domain.tld, domain2.tld und www.domain2.tld in der Datei „/var/log/squid/access.log“ gespeichert.

Um eine gute Kontrolle über die Domains zu haben, sollte jede Domain einzeln freigegeben werden. Das erhöht die Sicherheit, da keine anderen Domains über den Proxy-Server angefragt werden können. Die Zugriffsrechte werden beim Squid-Server über die Konfigurationsvariable „acl“ und „http_access“ gesteuert.

Bei dieser Konfiguration wird der Zugriff auf www.domain.tld von außen erlaubt. Der Rechner mit der IP-Adresse 192.168.1.1 darf zusätzlich noch auf „dev.domain.tld“ zugreifen. Es gibt durchaus auch die Möglichkeit, pauschal alles zu erlauben, was jedoch nicht zu empfehlen ist. Weitere Informationen gibt es im Manual von Squid.

Bei beiden Squid Versionen muss der Webserver auf den Port 80 auf 127.0.0.1 „hören“. Für Apache könnte es folgendermaßen Konfiguriert werden, wobei es wichtig ist, dass nicht die Zugriffsstatistiken vom Apache ausgewertet werden. Die Log-Datein vom Squid sind zu nutzen.

Damit TYPO3 die richtigen Cache-Zeiten (sog. Cache-Header) an den Proxy-Server sendet, müssen folgende Zeilen in das TYPOScript-Template eingetragen werden:

Manchmal ist das Löschen des gesamten Cache des Proxy-Servers nötig. Es geschieht durch die Eingabe von folgenden Befehlen:

Ist eingestellt, dass ein eintägiger Cache um Mitternacht gelöscht wird, entsteht für den ersten Nutzer nach Mitternacht eine Wartezeit, weil für ihn die Seite neu generiert wird. Mit einem Aufruf der Seite mit „wget“ kann der Proxy sie rechtzeitig für den ersten Nutzer cachen:

Die Zeile ruft alle Daten der Webseite einmal auf und speichert sie auf der Festplatte – dabei kann sehr viel Plattenplatz in Anspruch genommen werden (je nach Größe der Webseite). Deswegen darf nicht vergessen werden, die Daten nach der Generierung wieder zu löschen.

Ein Problem kann enstehen, wenn in der „squid.conf“ einer der Parameter „header_access“ gesetzt ist. Dann kann es vorkommen, dass man sich nicht in das TYPO3-Backend einloggen kann.

Für kleine Webseiten mit wenig Traffic lohnt sich kein Proxy-Server. Für Seiten mit viel Traffic und vielen Nutzern kann der Einsatz eines Squid-Proxy-Servers einen erheblichen Performanceschub bringen. Auch kleinere Ausfälle des Webservers können mit dem Proxy-Server abgefangen werden.