SQL Server in-Memory OLTP – Ein Plädoyer für Lasttest Werkzeuge und End-to-End Monitoring
Im Rahmen einiger Proof-of-Concepts und Workshops für die in-Memory OLTP Engine des SQL Servers habe ich die Erfahrung gemacht, dass selbst komplexe Eigenentwicklungen von Unternehmen häufig ohne Werkzeuge für realistische Lasttests auskommen müssen.
Ziel der PoCs ist es zu evaluieren, ob das Investment in die Integration von SQL Server in-Memory OLTP überhaupt einen wirtschaftlich gerechtfertigten Vorteil mit sich bringt. Die einfache Frage im Raum ist häufig: Wird unsere Anwendung mittels in-Memory OLTP tatsächlich deutlich schneller? Die Voraussetzung für eine solche Überlegung ist natürlich, dass man entweder zurzeit mit der bestehenden Last zu langsam unterwegs ist oder für die Zukunft mit wesentlich mehr Last rechnet und davon ausgeht, dass diese zu Problemen führen wird.
Die wenigsten Kunden nutzen zurzeit die in-Memory OLTP Engine des SQL Servers für eine komplette Neuentwicklung auf der grünen Wiese. Wobei, wer als ISV oder Entwicklungsleiter schon länger eine Neuentwicklung im Auge hatte, dann ist der SQL Server 2016 ein guter Grund nun endlich damit zu beginnen. Die Implementierung von in-Memory OLTP in eine bereits produktive Anwendung ist immer mit Aufwand verbunden. Dieser besteht i.d.R. aus Lizenzkosten (Enterprise Edition, sofern nicht eh schon gesetzt) und natürlich Aufwand für die Anpassung der Anwendung. In-Memory OLTP basiert ja u.a. auf einem Versionstore und damit einem optimistischen Konzept hinsichtlich von Änderungen an den Daten. Daher müssen die Entwickler häufig diesbezüglich erst geschult und gecoacht werden.
Nur lohnt sich dieser Aufwand auch wirklich? Dann kommt oft noch die Definitionsrunde, was denn nun eigentlich mit schneller gemeint ist. Nur oft kann diese Frage gar nicht in der ersten Runde seriös und abschließend geklärt werden, da Werkzeuge fehlen, um eine realistische Last auf einem Testsystem zu erzeugen.
Die Funktionsweise von in-Memory OLTP selbst kann ich mittlerweile sehr gut demonstrieren mit Open Source Werkzeugen und meinen eigenen Beispielszenarien. Nur hat sowas ja nichts zu tun mit der Last eines selbst entwickelten Webshops oder einer angepassten ERP Umgebung. Ohne Tests sind Aussagen über mögliche Verbesserungen reine Kaffeesatzleserei.
Der Verzicht auf die Entwicklung von Lasttest Werkzeugen und ein End-to-End Monitoring sind aus meiner Sicht eindeutig technische Schulden. Natürlich kann ich nachvollziehen, dass das unglaublich unattraktive Stories sind und gerade hier gerne am Ende eines Projektes Budget gespart wird.
Der Lasttest wird ersetzt durch ein generisches Monitoring des SQL Servers (wenn überhaupt…) und das End-to-End Monitoring ergibt sich durch den Durchschnitt der Tickets mit dem Label “Performance”.
Mir ist es ein Rätsel, wie ohne Lasttests eine Anwendung überhaupt hinsichtlich irgendwelcher Seiteneffekte durch mehrere Anwender getestet werden konnte. Wobei damit dann häufig auch deutlich wird, warum man überhaupt vor Ort ist, um diese zu tunen bzw. warum sich da jemand Vorteile durch die in-Memory Engine verspricht.
Ähnliches gilt für das End-to-End Monitoring. Die vorhandenen SLAs beschränken sich zumeist auf RTO & RPO. Kennzahlen darüber hinaus sind nicht definiert und “Effekte” im Frontenderlebnis nicht nachvollziehbar.
Daher meine Bitte an Alle: Implementiert Lasttests, welche auch weiter entwickelt werden mit der Anwendung, und gleich dazu noch ein End-to-End Monitoring drauf, damit evtl. Effekte frühzeitig bemerkt werden können.
Natürlich wäre dann auch der Beweis, dass in-Memory OLTP genau diesen Workload beschleunigt wesentlich einfacher zu erbringen und mit weniger Aufwand möglich. So verbringe ich nicht unwesentlich viel Zeit in den PoCs und entwickle rudimentäre Lasttests, um den Budgetverantwortlichen zumindest eine grobe Einschätzung der Möglichkeiten liefern zu können.
