Stark frequentierte Websites entlasten: TYPO3 mit Proxy-Server
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.
Installation und Konfiguration des Proxy-Servers
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“ [1] 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:
icp_port 0 cache_mem 800 MB cache_replacement_policy heap GDSF cache_dir ufs /var/spool/squid 1000 16 256 emulate_httpd_log on redirect_rewrites_host_header on visible_hostname www.domain.tld forwarded_for off
Listing 1
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:
http_port 1.2.3.4:80 # 1.2.3.4 muss an die eigene IP Angepasst werden httpd_accel_port 80 httpd_accel_host 127.0.0.1 httpd_accel_single_host on httpd_accel_with_proxy on httpd_accel_uses_host_header on
Listing 2
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:
http_port 1.2.3.4:80 vhost vport=80 defaultsite=127.0.0.1 cache_peer 127.0.0.1 parent 80 0 originserver no-query default url_rewrite_host_header on
Listing 3
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:
logformat combined %>a %ui %un [%tl] "%rm %ru HTTP/%rv" %Hs %<st "%{Referer}>h" "%{User-Agent}>h" %Ss:%Sh %<A %mt
acl regel_domain_tld dstdomain www.domain.tld
acl regel_domain_tld dstdom_regex (www\.)?domain2.tld
access_log /var/log/squid/access.log combined regel_domain_tld
Listing 4
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.
Konfiguration von Zugriffsrechten
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.
acl okdomains dstdomain www.domain.tld domain.tld acl devdomains dstdomain dev.domain.tld acl internal_ips src 192.168.1.1 http_access allow internal_ips devdomains http_access deny devdomains http_access deny !okdomains
Listing 5
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 [2].
Konfiguration des Webservers
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.
Listen 127.0.0.1:80 NameVirtualHost 127.0.0.1:80 <VirtualHost 127.0.0.1:80> ServerName www.domain.tld ... </VirtualHost>
Listing 6
Konfiguration von TYPO3
Damit TYPO3 die richtigen Cache-Zeiten (sog. Cache-Header) an den Proxy-Server sendet, müssen folgende Zeilen in das TypoScript-Template eingetragen werden:
config {
sendCacheHeaders = 1
cache_clearAtMidnight = true
cache_period = 86400
}
Listing 7
Wichtig ist, dass TYPO3 mit RealURL konfiguriert wird und funktionieren muss, da der Proxy-Server die Seiten anhand der URL cached. Bei dynamischen Seiten, die öfter pro Tag aktualisiert werden, empfiehlt sich zudem das Setzen des „Cache-expires“ Feldes bei den Seiteneinstellungen (Abb.). Selbst bei einem Webprojekt, dessen Inhalt ständig wechselt, sollte die „cache_period“ auf 60 eingestellt sein. Schon diese Minute Speicherung kann die Performance der Webseite um 40 Prozent steigern. Damit TYPO3 die Seiten auch cachen kann, muss gewährleistet werden,
dass keine Extension mit „USR_INT“ oder „COA_INT“ geladen wird.
Ebenfalls darf innerhalb des TypoScripts kein „temp.xxx“ vorhanden
sein. Die „temp.xxx“-Bereiche können in vielen Fällen durch „lib.xxx“
ersetzt werden.
Information für den Betrieb des Proxy-Servers
Manchmal ist das Löschen des gesamten Cache des Proxy-Servers nötig. Es geschieht durch die Eingabe von folgenden Befehlen:
/etc/init.d/squid stop squid -z /etc/inid.d/squid start
Listing 8
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:
wget --cache=off -r http://www.domain.tld/
Listing 9
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.
Fazit
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.
Marcel Alburg wohnt in Berlin und arbeitet nebenberuflich als Freelancer im Bereich Web- und Systementwicklung. Seit 2002 setzt er Webseiten mit TYPO3 um. Auf seiner Website www.weeaar.com findet man weitere Informationen über Projekte und TYPO3-Extensions.
