OXID-Setups bisher

OXID-Shops bestehen bisher oftmals aus mehreren PHP-Applikation-Servern und – jetzt kommt der Knackpunkt – einem Datenbank-Server.

Warum nur ein Datenbank-Server?

Leider unterstützt OXID nativ nur eine Datenbank. Für viele kleine Shops reicht das völlig aus. Bei unseren Zöglingen jedoch wird die Datenbank zum Bottleneck. Wenn die Datenbank überlastet ist, helfen auch keine weiteren Applikation-Server mehr. Der einzige Ausweg ist dann ein größerer Datenbank-Server. Aber was, wenn es keinen größeren Server mehr gibt? Mehr als 24 CPU-Kerne gibt es heute nun mal nicht zu kaufen. Wem also der größte Datenbankserver nicht ausreicht, muss erfinderisch werden. In der Version 5.0 wird OXID dieses Problem angehen, wir freuen uns schon sehr auf diese Änderung. Für alle Performancehungrigen, die nicht bis dahin warten können (oder wollen), haben wir bereits heute eine Lösung!

Zukünftige OXID-Setups bei SysEleven

Durch eine SysEleven-Erweiterung in OXID können Datenbankanfragen des Shops nunmehr auf mehrere Server verteilt werden. Für die Echtzeit-Synchronisation der Datenbank-Server nutzen wir das altbekannte MySQL-Feature “Master-Slave-Replikation”.

In dem hier dargestellten Setup werden die Anfragen von zwei Datenbank-Servern abgearbeitet. Dadurch erhöhen wir die Gesamtkapazität (nicht die Geschwindigkeit) des Shops und kommen dem horizontalen Skalieren wieder einen Schritt näher. Einziger Nachteil der Master-Slave-Replikation ist, dass man in der Slave-Datenbank nur lesen darf (read only), Änderungen der Daten müssen immer auf dem Master erfolgen.

Wie viel bringt es?

In einer Referenzmessung konnten wir die CPU-Belastung im Datenbank-Master auf die Hälfte reduzieren, sobald Abfragen auch vom Slave abgearbeitet wurden.

Je besser die Last verteilt werden kann, umso höher ist die Kapazität des Shops, d.h. umso mehr gleichzeitige Besucher können bedient werden. Wem die zusätzliche Power von einem Datenbank-Slave nicht ausreicht, kann einfach mehrere Slaves verwenden.

Welche Queries werden auf die Slaves ausgelagert?

Wie bereits erwähnt, dürfen die Slaves nur lesen und keine Daten verändern. Zudem gibt es Queries, z.B. während des Bestellprozesses, die zwingend auf dem Master ausgeführt werden sollten. Wir müssen also aufpassen, welche Queries wir vom Master und welche von den Slaves verarbeiten lassen. Üblicherweise unterscheidet man an dieser Stelle ganz simpel zwischen lesenden (select) und schreibenden (insert, update, delete, replace) Queries. Das reicht uns jedoch nicht: Wir wollen keine gleichmäßige Verteilung, sondern den bestmöglichen Performancegewinn. Um das zu realisieren, ist es entscheidend, die richtigen Queries auf die Slaves auszulagern. Eine Query, die beispielsweise nur 5% der gesamten MySQL-Rechenzeit ausmacht, kann gerne auf dem Master bleiben, wenn dafür eine andere Query, die für 30% der Rechenzeit verantwortlich ist, verteilt werden kann. Wir suchen also die “teuren” Queries! Dazu erstellen wir ein individuelles MySQL-Profiling für Ihren Shop und ermitteln die 5 oder 10 “teuersten” Queries. Meistens machen diese Queries summiert mehr als 70% oder 80% der gesamten MySQL-Rechenzeit aus.

Wann bekommt Ihr OXID-Shop den SysEleven-Faktor?

Wir bei SysEleven tun alles dafür, um Euch Shopbetreibern während dieser Zeit zumindest eine Sorge abzunehmen. Die Arbeitsteilung ist dabei ganz simpel: Ihr konzentriert Euch auf das Business, wir kümmern uns um die Server. In der SysEleven Private Cloud können wir jedem Server während des Betriebs mehr Power geben, damit wir ruckelfrei durchs Weihnachtsgeschäft kommen.

Die Erleichterung wird sofort sichtbar, so sehen glückliche Server aus:

Im Namen des gesamtem SysEleven-Teams wünsche ich Euch allen eine erfolgreiche und sorgenfreie Weihnachtszeit. Und jetzt keine Blogs mehr lesen, sondern ab an die Arbeit, die Kunden warten auf die Pakete.

Wirkungsweise

Der OXID Super Cache wird vor die eigentlichen Shop-Server geschaltet und kann dort einen wesentlichen Teil des Traffics abfangen und beschleunigen. Die Lastverteilung und Wirkungsweise ist in den beiden folgenden Grafiken dargestellt.

Alle Anfragen an den Shop werden von PHP und MySQL bearbeitet und bei jedem einzelnen Seitenaufruf aufs Neue berechnet, zusammengebaut und zum Schluss ausgegeben. Web- und Datenbankserver sind ständig belastet.

Der OXID Super Cache speichert das fertige HTML und liefert es ab dem zweiten Aufruf derselben Seite direkt aus. Nur noch ein Bruchteil der Anfragen schlagen auf Web- und Datenbank-Server durch. Das entlastet die Systeme und sorgt für mehr Performance und steigert die Kapazität.

Zahlen und Fakten

Durch den OXID Super Cache werden die Server nicht nur entlastet, der Cache ist auch sehr viel performanter als ein Webserver und kann die Seiten um ein Vielfaches schneller ausliefern. Die spezielle Abstimmung auf höchste Performance macht den Super Cache sogar noch schneller als den OXID Dynamic Content Cache in der Enterprise Edition.

Durch den Einsatz des OXID Super Caches können Sie die Seitenladezeit auf ca. 0,1 Sekunde verringern. Dieser Wert wird hauptsächlich durch die Geschwindigkeit der DSL-Verbindung begrenzt, direkt am Cache gemessen beträgt die Seitenladezeit sogar nur 0,01 Sekunde.

Alle Seitenaufrufe, die direkt vom Super Cache ausgeliefert werden, verursachen keine einzige Abfrage in der Datenbank.

Der Super Cache ist auf hohen Durchsatz optimiert und kann im Vergleich zu Webservern ein Vielfaches an Seiten pro Sekunde ausliefern. Das ist besonders wichtig bei High-Traffic-Kampagnen wie zum Beispiel TV-Werbung, sehr großen Newsletter-Verteilern oder Ein-Tages-Gutscheinaktionen.

Wie viel bringt der Super Cache?

Die folgende Grafik zeigt die Erfolgsquote des Cachings bei einem unserer Kunden. 64% aller Seitenaufrufe werden aus dem Cache ausgeliefert. Das bedeutet, mehr als die Hälfte aller Zugriffe sind rasend schnell und verursachen keine Last auf den Servern. Die Shop-Server müssen sich nur noch um die Hälfte der Zugriffe kümmern.

Intelligentes Caching

Die Idee einzelne Elemente nicht jedes mal neu zu berechnen, sondern zwischenzuspeichern ist nicht neu. Ganz im Gegenteil, simples Caching kann heutzutage fast jede Software. Das besondere am OXID Super Cache ist die intelligente Cacheverwaltung. Wenn sich ein Artikel ändert oder ausverkauft ist, werden automatisch alle Seiten aus dem Cache entfernt, auf denen der Artikel zu sehen ist. Dadurch sind Sie nicht mehr wie bisher üblich an Cache-Laufzeiten gebunden, sondern Änderungen werden sofort sichtbar.

Referenz-Installation

Überzeugen Sie sich selbst von der Performance des OXID Super Cache. Bei unserem Kunden http://www.schuhtempel24.de/ können Sie ausprobieren wie schnell Ihr Shop sein könnte. Mit über 1 Million Seitenaufrufen pro Tag zählt Schuhtempel24 zu den High-Traffic OXID Installationen. Unser Super Cache macht den Shop schneller als die Konkurrenz erlaubt.

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? ;-)

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