Performance des SQL-Servers

Vertec wird bevorzugt mit der Open-Source-Datenbank Firebird betrieben. Ich habe vor einiger Zeit einen Blogartikel mit dem Titel Warum Vertec auf Firebird als Datenbankserver setzt geschrieben. Weil es hier um die Performance von MS SQL-Server geht, zitiere ich einen Abschnitt aus diesem Blogartikel:

«Performance: Für die allermeisten Operationen ist Firebird schneller als beispielsweise MS SQL-Server, der mit viel mehr Overhead zu kämpfen hat.»

An dieser Aussage gibt es nichts zu rütteln: Für die allermeisten Vertec Einsatzszenarien ist Firebird die bessere Wahl. Er bietet bessere Performance, weniger Komplexität und ist einfacher im Betrieb.

Da es jedoch auch (grössere) Vertec Kunden gibt, die mit gutem Grund auf MS SQL-Server setzen, möchte ich das Thema «Performance des SQL-Servers» hier noch etwas vertiefen.

Die Kernaussage vorweg: Ein MS SQL-Server auf «shared» Cloud-Hardware liefert schlechte bis sehr schlechte Resultate.

Es geht dabei vor allem um den Query Analyzer. Diese Softwarekomponente analysiert eine eingehende, in SQL formulierte Query zuerst und erarbeitet einen bestmöglichen Plan, wie sie effizient ausgeführt werden kann. Die Erfahrung zeigt, dass der Query Analyzer sich dafür viel Zeit nimmt. Anscheinend hat Microsoft um 2014 einen «verbesserten» Query Analyzer eingeführt, der aber auch mehr Ressourcen beansprucht. Der erhöhte Ressourcenbedarf, vor allem an CPU-Leistung, führt dazu, dass der Query Analyzer sehr empfindlich auf fehlende CPU-Ressourcen reagiert, z. B. bei einer «shared CPU» (vCPU) in einer virtuellen Maschine.

Die folgenden Messungen sollen dies verdeutlichen. Die Laufzeiten von Firebird und MS SQL-Server sind direkt vergleichbar, denn es handelt sich um dieselbe Vertec Datenbank auf demselben Server. Getestet wurde eine komplexe SQL-Query mit mehreren verschachtelten Unterabfragen, z. B. WHERE bold_id IN(SELECT project FROM ...), wie sie in Vertec in SQL-Ordnern oder über Python mit vtcapp.getwithsql() üblich sind.

Firebird verarbeitet die Query konstant in 16ms (0.016s), während der SQL-Server ganze 9s für dieselbe Query benötigt! Aber was macht der SQL-Server während dieser Zeit? Allein 8.6s braucht er, um die Query zu kompilieren. Die Ausführung dauert danach nur noch weniger als 500ms.

In der Informatik sind 8.6s eine halbe Ewigkeit. Man kann diese Zeit deutlich reduzieren, wenn man dem Query Analyzer, der nur einen Thread nutzen kann, genügend CPU-Ressourcen gibt, nämlich einen Core, der nicht anderweitig beschäftigt ist und sich voll auf die sehr lange Rechenzeit konzentrieren kann, die der Query Analyzer anfordert.

Um den Einfluss genauer abzuschätzen, haben wir dieselbe Query mit derselben Datenbank einmal auf «schlechterer» (weil shared) Cloud-Infrastruktur laufen lassen und einmal auf einer lokalen, nicht virtualisierten Infrastruktur («Blech»). Der Unterschied ist frappant: Der Query Analyzer, der sich im Cloud-Szenario 8.6s Zeit lässt, erledigt exakt dieselbe Arbeit auf der lokalen Infrastruktur in 0.3s. Das ist immer noch massiv langsamer als Firebird, aber doch eher im akzeptablen Bereich!

On-Premises-Kunden, die Vertec mit SQL-Server einsetzen wollen, sollten diesen also auf möglichst performanter, lokaler Hardware betreiben. Ist das nicht möglich, muss bei Cloud-Infrastruktur darauf geachtet werden, dass Hardware-Ressourcen möglichst nicht mit anderen VMs geteilt werden. Will man Vertec in der Cloud performant betreiben, empfiehlt sich dringend der Einsatz von Firebird.