Software

Bessere Performance mit TYPO3: Frisiert und aufgebohrt

Seite 2 / 4

Betriebssystem

Die Wahl des Betriebssystems macht in
manchen Fällen einen erkennbaren Performance-Unterschied aus.
Einige bekannte Benchmark-Vergleiche betonen, dass Linux 2.6 sowohl
in Hinsicht auf Apache als auch MySQL eine höhere Leistung
bietet als die Version 2.4 [2]
[3]. Auch skaliert Linux besser als die
freien BSD-Derivate, ganz zu schweigen von Windows oder Solaris [4].

Viele dieser Benchmarks waren entweder
„low-level“-Tests oder wurden auf extrem leistungsfähiger
Hardware (große Multiprozessor-Systeme) durchgeführt . Für
unsere Zwecke überprüften wir, ob ein einfaches Ersetzen
des vorhandenen 2.4.x Kernels mit der Version 2.6.14.x und das
Aktivieren der Native Posix Threads Library (NPTL) die Performance
erhöhen. Die Auswirkungen waren jedoch kaum messbar und nicht
einmal auf einem beständigen Niveau. Das Ergebnis lag immer noch
im Bereich von 4 Req/s.

Bedeutet das, dass eine Anpassung des
Betriebssystems sinnlos ist? Nein, aber in unserem Fall war dies
einfach nicht der signifikante Engpass. Dennoch sollten Sie Ihr
System NPTL-fähig machen, um Threads statt Prozesse zu nutzen.
Im Vergleich zu Prozessen reduzieren Threads zum Beispiel die durch
Apache 2.0 verursachte Systemauslastung deutlich. Das bedeutet aber
keinesfalls, dass Seiten automatisch schneller ausgeliefert werden
(siehe unten).

MySQL-Datenbank

Oft wird
angenommen, die Datenbank sei der Grund für eine schlechte
Performance. Wir wissen, dass TYPO3 erstere ziemlich intensiv nutzt.
Es führt für jede einzelne Anfrage mehrere Abfragen durch,
zum Beispiel, um Daten aus dem Cache zu holen und Sessions zu
aktualisieren. Die Optimierung von MySQL ist eine Wissenschaft für
sich und es existieren dazu sowohl unzählige Mythen als auch
nützliche Rezepte [5]. Wir haben uns lediglich darauf
konzentriert, einige Server-Parameter zu verändern und die
Auswirkungen zu messen, hier am Beispiel der MySQL- Version 4.1.

Zunächst erhöhten wir die
maximale Anzahl gleichzeitiger DB-Verbindungen auf 100 – da TYPO3
als Voreinstellung persistente DB-Verbindungen benutzt, entspricht
die Zahl ungefähr der Anzahl der MaxClients in Apache (siehe
unten). Diese Veränderung brachte zwar keine
Leistungssteigerung, schaffte aber Reserven für schnellere
Anfragen im späteren Verlauf der Testreihe.

CONFIG
my.cnf:
max_connections = 100

Listing 3

Weil wir
genug freien RAM-Speicher hatten, bot sich der Einsatz von „Query
Caching“ [6] an, um die vielen sich wiederholenden Abfragen von
TYPO3 leichter bewältigen zu können.

CONFIG
my.cnf:
query_cache_limit = 2M
query_cache_size = 64M
query_cache_type = 1
table_cache = 256
key_buffer_size = 64M

Listing 4

Anschließend
deaktivierten wir das Logging von DB-Abfragen, weil wir keine
weiteren MySQL-Datenbanken zur Replikation einsetzten und unsere
Backup-Strategie nicht darauf basierte, jeden Schreibzugriff
aufzuzeichnen.

CONFIG
my.cnf:
log-bin

Listing 5

Auch nach den
Änderungen an der Datenbank hatte sich die Leistung nicht
wesentlich verändert: 4 Req/s. Ein Blick auf die Ausgabe von
mysqladmin status zeigte, dass das Caching sehr gut funktionierte. Wo
war also das Problem? Wie zuvor beim Betriebssystem stellte sich
heraus, dass die Datenbank nicht der vermutete Engpass war. Und zwar
aus zwei Gründen:

  1. Mit
    einer einzelnen Website hatten wir nicht so viele gleichzeitige
    Verbindungen, sodass das Erstellen von Threads für Anfragen
    kein Problem darstellte. Das wäre bei mehreren parallel
    installierten Websites anders.
  2. Die
    Quickstart-Website lieferte (größtenteils) statische
    Inhalte, die ausgezeichnet von MySQL zwischengespeichert werden
    konnten. Das würde sich mit dynamischeren Inhalten ändern.

Webserver – Apache und Alternativen

Der folgende Abschnitt befasst sich
mit der Optimierung und dem Vergleich von Apache 1.3 und 2.0.
Zusätzlich schauen wir uns den verhältnismäßig
neuen und schlanken Webserver lighttpd [7] an.

Apache 1.3 für TYPO3 zu
optimieren war nicht gerade eine hohe Wissenschaft, da wir
hauptsächlich mit den Parametern herumspielten, die mit dem
Verteilen auf Unterprozesse zu tun hatten. Das Hauptproblem war die
maximale Anzahl der erstellten Unterprozesse (MaxClients). Der
Standard-Wert von MaxClients liegt bei Debian bei 150, was für
statische Inhalte auch vollkommen angemessen ist. Sobald jedoch TYPO3
ins Spiel kommt, verarbeitet jeder dieser Apache-Prozesse über
mod_php auszuführenden Code, was eine immense Belastung für
CPU und Speicher darstellt. Unser System war nicht leistungsstark
genug, um eine derartige Menge an gleichzeitigen Anfragen zu
bewältigen und daher innerhalb von Sekunden überlastet. Die
Anzahl gleichzeitig erlaubter Prozesse musste also so weit reduziert
werden, dass das System noch unterhalb seiner Leistungsgrenze
arbeitet.

CONFIG
httpd.conf:
MaxClients 32

Listing 6

Eine bessere
Lösung versprach Apache 2.0, mit dem ein neues Prozessmodell
vorgestellt wurde, welches keine rechenintensiven Prozesse, sondern
vergleichsweise wenig aufwändige Threads erzeugt. Das so
genannte „mpm-worker“-Modul verbraucht Berichten zufolge deutlich
weniger Ressourcen [7]. Leider arbeitet es zurzeit noch immer nicht
vollständig stabil mit mod_php zusammen, obwohl sich auch
positive Erfahrungsberichte im www und usenet finden. Hinreichend
stabil dagegen ist das “mpm-prefork”-Modul (ohne Threading),
welches mit TYPO3 in etwa die gleiche Systemlast erzeugte wie Apache
1.3.

Zur Steigerung der Performance von
Apache haben wir an einigen gängigen Stellen der Konfiguration
Änderungen vorgenommen, allerdings ohne nennenswerte
Verbesserungen. Das Logging wurde minimiert. Im Produktivbetrieb wird
ohnehin empfohlen, das Fehlerprotokoll zu reduzieren:

CONFIG
httpd.conf:
LogLevel warn

Listing 7

Um die Zahl
der Dateizugriffe zu verringern, kann man das Überschreiben von
Konfigurationsdirektiven verbieten. Andernfalls wird bei jeder
Anfrage rekursiv nach htaccess-Dateien auf der Festplatte gesucht:

CONFIG
httpd.conf:
AllowOverride None

Listing 8

Verzögerungen
durch DNS-Rückfragen für das Zugriffs-Log sollten stets
abgeschaltet werden. Der Logfile-Analyzer kann dies problemlos im
Nachhinein übernehmen:

Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Schreib den ersten Kommentar!

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!

Hey du! Schön, dass du hier bist. 😊

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team bestehend aus 65 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Danke für deine Unterstützung.

Digitales High Five,
Stephan Dörner (Chefredakteur t3n.de) & das gesamte t3n-Team

Anleitung zur Deaktivierung