Seit nunmehr drei Jahren arbeiten wir intensiv an der Performance-Steigerung von OXID-Shops und haben so einigen Lahmen wieder das Rennen beigebracht. Heute können wir mit Stolz behaupten, dass wir nun auch die letzte Skalierungsbarriere überwunden haben: Datenbankskalierung bei OXID.
OXID-Setups bisher
OXID-Shops bestanden bisher oftmals aus mehreren PHP-Applikation-Servern und – jetzt kommt der Knackpunkt – einem einzigen 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 wird die Datenbank jedoch zum Bottleneck. Wenn die Datenbank überlastet ist, helfen auch keine weiteren Applikation-Server mehr. Der einzige Ausweg ist ein größerer Datenbank-Server. Aber was, wenn es keinen größeren Server mehr gibt? Mehr als 24 CPU-Kerne gibt es heute einfach nicht zu kaufen. Wem also der größte Datenbankserver nicht ausreicht, der muss erfinderisch werden oder geduldig sein. Wer geduldig sein möchte, wartet auf die Version 5.0 von OXID, denn hier wird dieses Problem gelöst- Für alle anderen hat SysEleven bereits JETZT eine Lösung!
Zukünftige OXID-Setups bei SysEleven
Durch eine SysEleven-Erweiterung in OXID werden die Datenbankanfragen des Shops auf mehrere Server verteilt. 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. Folglich erhöht sich die Gesamtkapazität (nicht die Geschwindigkeit) des Shops und wir sind dem horizontalen Skalieren wieder einen Schritt näher gekommen. 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, vorausgesetzt dass die Abfragen auch vom Slave übernommen wurden.
Je besser die Last verteilt wird, umso höher ist die Kapazität des Shops, d.h. es können gleichzeitig mehr Besucher 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?
