Im heutigen Teil dieser Reihe geht es um die Steigerung der Performance von Webseiten oder E-Commerce Shops. Manche unserer Kunden nennen das „Serverpower“ oder gerne auch „Vollgas Hosting“. Und da haben wir auch schon das Missverständnis: Natürlich gehören zu einer schnellen Webseite auch schnelle Server – aber nicht nur. Die Performance der Software ist ebenso wichtig. Die besten und schnellsten Server machen Ihre Webseite nicht schneller, wenn die Software mit angezogener Handbremse fährt – und umgekehrt genauso.

Die Performance einer Webseite wird durch das schwächste Glied der Kette bestimmt und nicht etwa durch die schnellste Komponente des Setups, wie viele irrtümlich glauben.

Die erste und wichtigste Teilaufgabe bei der Optimierung von Webperformance lautet also: Finde das schwächste Glied der Kette. Fachleute nennen das den Flaschenhals bzw. das Bottleneck. Je mehr Änderungen es beispielsweise an einem Online-Shop gab und je mehr Köche den Brei gerührt haben, umso komplexer und schwieriger wird die Suche nach dem Bottleneck. Erschwerend kommt hinzu, dass es laut unserer Erfahrung im Grunde nie ein einzelnes, sichtbares Bottleneck gibt. Meistens finden wir eine Verkettung „unglücklicher Umstände“ und „gewachsener Strukturen“, die gemeinsam die Performance in den Keller ziehen. Nicht selten finden wir sogar Features, die schon lange nicht mehr benutzt werden, aber immer noch aktiv sind und Last erzeugen.

Was ist das Ziel?

Das Ziel des Performance-Profilings ist die Identifikation der Bottlenecks. Als Ergebnis dieser Analyse sollte ein Maßnahmenkatalog mit konkreten Verbesserungsvorschlägen und Aufgaben vorliegen. Im Übrigen gehört zum SysEleven Faktor auch, dass es an dieser Stelle eine strikte Trennung gibt: Wir helfen dabei die Bottlenecks zu finden und liefern eine Anleitung wie sie behoben werden können. Die hardware- bzw. serverseitige Umsetzung erfolgt direkt durch uns und die softwareseitige Umsetzung erfolgt durch die Agentur des Kunden bzw. durch die Entwickler, die das jeweilige Setup viel detaillierter kennen. Das beste Ergebnis lässt sich erzielen, wenn Hostinganbieter, Agentur und Entwickler zusammenarbeiten.

Wie finden wir die Bottlenecks?

Zunächst erfolgt eine Bestandsaufnahme: Server, Software, Versionsnummern, Konfigurationen, aktuelle Auslastung, Besonderheiten. Für die detaillierte Untersuchung der Performance unterteilen wir das Setup in zwei Kategorien: Komponenten und Seitentypen. Die einzelnen Komponenten etwa eines Shops sind die Shopsoftware (z.B. PHP), die Datenbank (z.B. MySQL) und externe Webservices (z.B. Suchanbieter). Jede dieser Komponenten kann Bottlenecks verursachen und wird deshalb einzeln analysiert und getestet. Im zweiten Schritt unterscheidet man zwischen verschieden Seitentypen, bei einem Shop sind das meist die Startseite, Kategorieseite, Produktseite und die Suche. Jeder dieser Seitentypen hat individuelle Funktionen und Anforderungen – und damit auch potentiell individuelle Bottlenecks.

Seitenladezeit

Einer der sichtbarsten Indikatoren für die Performance der Webseite ist die Seitenladezeit. Als Referenzwerte für eine spätere Erfolgsmessung wird die Ladezeit jedes Seitentyps einzeln gemessen:

Bottlenecks in MySQL finden

Bei der Analyse von MySQL unterscheiden wir im Wesentlichen zwischen zwei Arten von Last:

• Den Datenbankabfragen, die ein einzelner Aufruf eines Seitentyps verursacht.
• Der Gesamtauslastung aller Datenbankabfragen während des Livebetriebs.

Für jeden der ermittelten Seitentypen wird analysiert, welche Datenbankabfragen bei einem einzelnen Seitenaufruf ausgeführt werden. Die „teuersten“ Queries kommen auf die Merkliste für eine genauere Untersuchung. Ich habe schon so Einiges gesehen und bin dennoch immer wieder überrascht wie viele Datenbankabfragen von einem einzigen Seitenaufruf verursacht werden können. Mehrere Hundert sind hier leider keine Seltenheit! Da gibt es oft – ich formuliere es mal so – Verbesserungspotential. ;-)

In diesem Beispiel hat ein einzelner Aufruf der Startseite eines Online Shop 296 Datenbankabfragen verursacht, hier gibt es sicher den einen oder anderen Ansatzpunkt für eine genauere Untersuchung.

Die Gesamtbelastung der Datenbank wird untersucht, indem alle Datenbankabfragen, idealerweise während einer Lastspitze, in einem Logfile protokolliert werden. Aus diesem Logfile wird ein Query-Profil erstellt. Das ist eine nach Rechenzeit sortierte Liste ähnlicher Queries. Dabei ist die Verteilung der verbrauchten Rechenzeit relevant und nicht etwa die Ausführungszeit der einzelnen Queries. Dauert eine Abfrage beispielsweise sehr lange, wird aber nur selten ausgeführt, hat sie wenig Einfluss auf die Gesamtperformance. Uns interessiert also vielmehr, wieviel Anteil an der gesamten Datenbankrechenzeit auf ähnliche Queries entfallen.

Hier sieht man zum Beispiel, dass die obere Query (nur der Anfang ist dargestellt) 32,5% der gesamten MySQL-Rechenzeit ausgemacht hat. Diese Query ist somit unser Kandidat #1 auf dem Prüfstand ist. Ob es zusätzlich auch Queries gab, die 10 Sekunden gedauert haben, im Testzeitraum aber nur dreimal aufgerufen wurden, ist in der Gesamtbetrachtung der Performance unerheblich.

Zwischenstand

Bevor es an das PHP-Profiling geht, lohnt sich an dieser Stelle eine Zwischenrechnung, die für jeden der anfangs ermittelten Seitentypen einzeln angewendet wird:

Seitenladezeit – Summe der Zeit aller MySQL-Queries ≈ Ausführungszeit in PHP

Das Ergebnis entspricht nur sehr grob der PHP-Ausführungszeit, dennoch können wir den Wert an dieser Stelle als Entscheidungsgrundlage benutzen, ob sich jeder weitere Aufwand überhaupt noch lohnt oder ob die Bottlenecks bereits gefunden sind.

Bottlenecks in PHP finden

Für das Profiling in PHP gelten im Grunde dieselben Regeln wie für MySQL. Jeder Seitentyp wird einzeln untersucht. Auch hier ist besonders die Verteilung interessant. Welche Klasse oder Methode verursacht wie viel Prozent der gesamten Ausführungszeit?

Fazit

Die Performance einer Webseite zu steigern ist einfach – wenn man vorher die tatsächlichen Bottlenecks gefunden hat. Sehr oft begegnen uns Projekte, bei denen alle möglichen Best-Practices angewendet wurden und die Seite dennoch unbefriedigend langsam ist. Kein Wunder, wenn an den echten Bottlenecks vorbei-optimiert wurde. Der Erfolg bleibt aus und der Frust ist groß. Ein detailliertes Performance-Profiling ist zwar sehr komplex und aufwendig, es rentiert sich aber sehr schnell durch echte Ergebnisse.

Wann bekommt Ihre Webseite den SysEleven Faktor?

SysEleven ist spezialisiert auf High-Performance-Webseiten und wir sind stolz auf jedes einzelne bei uns betreute Projekt. Wir freuen uns persönlich über jede neue Herausforderung. Derzeit liegt der Rekord bei 1440 MySQL Queries für einen einzigen Seitenaufruf.

Wer bietet mehr? ;-)

Zuordnung zu URLs

In der Prozessliste fehlt uns jedoch eine entscheidende Information: Welche URL hat diesen Prozess ausgelöst, der außergewöhnlich viel Arbeitsspeicher verbraucht? Was wir suchen ist eine Zuordnung zwischen dem Prozess und der im Browser aufgerufenen URL. Da alle Zugriffe auf die Webseite im Apache Logfile protokoliert werden, liegt Nahe an dieser Stelle anzusetzen.

Unser Ziel ist also, innerhalb der Applikation den maximal verbrauchten Arbeitsspeicher zu ermitteln und den Wert an Apache zu übergeben, damit dieser im Logfile protokoliert werden kann. Wir nutzen hierfür die beiden PHP Funktionen memory_get_peak_usage() und apache_note():

# get the maximum ram
$debug_ram = memory_get_peak_usage();

# make it visible to apache
apache_note("x-php-ram", $debug_ram);


Implementierung in die Applikation

Wir wollen natürlich nicht in der Applikation suchen, an wie vielen Stellen wir den Code einfügen müssen, damit wir bei jedem Aufruf den RAM-Verbrauch messen können. Für unsere Debugzwecke machen wir uns eine globale Funktion zu nutze: In der php.ini können wir definieren, dass am Ende von jedem PHP Aufruf zusätzlicher Code ausgeführt wird:


; Automatically add files
;auto_prepend_file =
auto_append_file = /var/www/x-php-ram.php


Implementierung in Apache

Um die Werte auch wirklich im Logfile zu sehen, verändern wir das Logfileformat in Apache:


LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\" PHP-RAM: %{x-php-ram}n" combined_memory

CustomLog /var/log/apache2/access.log combined_memory


Ergebnis

Jetzt sehen wir wie viel Arbeitsspeicher jeder einzelne Aufruf einer Webseite verbraucht hat:


/ PHP-RAM: 91106128
/fotos/deutschland-besiegt-kanada PHP-RAM: 110486240
/page/hitfinder PHP-RAM: 81736024
/fotos/wetten-dass-abschied PHP-RAM: 96412776
/shows/schreckliche-urlaubsmode PHP-RAM: 98604800
/musik PHP-RAM: 95526032


In diesem konkreten Fall hat uns diese Debug-Information leider nicht weitergeholfen. Es gab keine Ausreißer, im Grunde haben alle Aufrufe ungewöhnlich viel Arbeitsspeicher verbraucht. In dieser Drupal-Installation sind sehr viele Module installiert, so dass tatsächlich viel RAM verbraucht wird. Durch den Einsatz von APC konnten wir letztendlich den RAM-Verbrauch auf die Hälfte reduzieren und das Problem entschärfen. Dazu aber mehr in einem anderen Blogpost…

APC ist ein so genannter “Opcode Cache”. Die Aufgabe von APC ist es, sich den aufwendigen Kompiliervorgang für spätere Zugriffe zu merken, damit dieser nur einmal ausgeführt werden muss. Bei jedem weiteren Aufruf der Datei liegt diese bereits vorkompiliert im Arbeitsspeicher.

Wie viel schneller wird meine Webseite?

Als Beispiel habe ich die Performance einer unserer WordPress-Installationen gemessen. Mit dem Tool Apache Bench (alternativ http_load oder jmeter) kann man ermitteln wie oft eine Webseite in einem festgelegten Zeitraum aufgerufen werden kann. Daraus ergibt sich die Geschwindigkeit der Webseite in der Einheit “Aufrufe pro Sekunde” (Requests per second). Je höher diese Zahl, desto schneller ist die Webseite. Oder anders herum, desto mehr Anfragen können je Zeiteinheit bearbeitet werden.

Test 1: WordPress mit standard PHP

Test 2: WordPress mit aktiviertem APC

Ein Fazit

WordPress ist mit APC knapp viermal schneller als ohne. Aber: Wie viel schneller eine Webseite tatsächlich wird, hängt von der verwendeten Software ab. Wichtig: Nicht jede Software ist kompatibel zu APC, aber ein Versuch lohnt sich allemal.

Die Auslastung des Caches und die Erfolgsquote (Hits/Misses) ist, stellt APC in Diagrammen dar:

Alternativen

Neben APC gibt es noch eAccelerator und XCache. Performancemäßig nehmen die drei sich wenig, welche Software man einsetzt ist eher Geschmacksache bzw. eine Frage der Kompatibilität – was mit dem einen Cache nicht kompatibel ist, wird mit einem anderen vielleicht doch funktionieren. Das hartnäckige Gerücht, Zend Optmizer gehöre auch dazu, ist übrigens falsch. Zend Optimizer “optimiert” zwar den Quellcode, ist aber kein Cache und merkt sich diese Verbesserungen nicht. Im Gegenteil: Die gleiche Arbeit wird bei jedem Aufruf erneut ausgeführt. Aus Sicht der Performance ist das wenig förderlich, weil es durch die ständige Mehrarbeit die Ausführung von PHP sogar noch verlangsamen kann.

Links

http://de.php.net/manual/de/book.apc.php
http://www.zend.com/de/community/php
http://eaccelerator.net/
http://xcache.lighttpd.net/
http://httpd.apache.org/docs/2.2/programs/ab.html