Seit nunmehr drei Jahren beschäftigen wir uns intensiv mit der Performance-Steigerung von OXID-Shops und haben in dieser Zeit so einigen lahmen wieder Beine gemacht. Heute sind wir besonders stolz darauf, dass wir nun auch die letzte Skalierungsbarriere meistern konnten: Datenbankskalierung bei OXID.

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?