Im Beitrag NAV 2016 + Azure SQL = Performance? habe ich einen kurzen Test zum Thema NAV 2016 + Azure SQL durchgeführt. Dabei sollte die Performance des Setups per „Mandanten kopieren“ gemessen werden. Das Ergebnis war ernüchternd: NAV brauchte mit Azure SQL 3mal so lange wie die Variante, in der die SQL-Datenbank auf der VM-Festplatte C:\ liegt!
Die Frage ist nun: Kann man mit Azure-Einstellungen die Performance steigern?
Im ersten Test dienten als Basis die kleinste Azure VM (Standard D1 mit 1 Kern und 3.5 GB RAM) und die kleinste Standard Azure SQL-Instanz (S0 mit 10 DTU). Was passiert, wenn man dem Setup etwas mehr PS unter die Haube gibt?
Umstellung der DTUs
Zum Glück ist das für Azure SQL sehr einfach: Im alten Azure-Portal geht es über SQL-Datenbanken > [gewünschte Datenbank] > Skalieren. Dort kann man die entsprechenden Leistungsparameter einstellen. Es gibt auch nur 2: Die Größe der Datenbank und die Anzahl der DTUs. Ich bin kein Azure SQL-Experte, aber die DTUs geben wohl an, wie viel Power die SQL-Datenbank hat.
06
Im neuen Azure-Portal geht es so:
Nach Umstellung und Speichern dauert es 5-15 Minuten, bis die neue Einstellung aktiv ist.
Also probieren wir mal aus, was passiert, wenn wir dem Setup statt nur 10 dann 20, 50 oder 100 DTUs geben. Wieder wird der NAV 2016 CRONUS Mandant kopiert. Diesmal allerdings nur jeweils 3mal. Mehr Messungen sind m.E. nicht notwendig, wenn die Werte sind recht stabil.
Ergebnisse
Hier die Ergebnisse:
Lauf | VM | VM Kerne | VM RAM (GB) | SQL Leistungsebene | SQL DTUs | Zeit | |
---|---|---|---|---|---|---|---|
1 | D1 | 1 | 3,5 | S0 | 10 | 02:54 | |
2 | D1 | 1 | 3,5 | S0 | 10 | 02:46 | |
3 | D1 | 1 | 3,5 | S0 | 10 | 02:52 | |
4 | D1 | 1 | 3,5 | S1 | 20 | 02:04 | |
5 | D1 | 1 | 3,5 | S1 | 20 | 01:42 | |
6 | D1 | 1 | 3,5 | S1 | 20 | 01:42 | |
7 | D1 | 1 | 3,5 | S2 | 50 | 01:19 | |
8 | D1 | 1 | 3,5 | S2 | 50 | 01:17 | |
9 | D1 | 1 | 3,5 | S2 | 50 | 01:16 | |
10 | D1 | 1 | 3,5 | S3 | 100 | 01:02 | |
11 | D1 | 1 | 3,5 | S3 | 100 | 01:03 | |
12 | D1 | 1 | 3,5 | S3 | 100 | 01:05 | |
13 | D4 | 8 | 28 | S0 | 10 | 03:07 | |
14 | D4 | 8 | 28 | S0 | 10 | 02:52 | |
15 | D4 | 8 | 28 | S0 | 10 | 02:56 | |
16 | D4 | 8 | 28 | S3 | 100 | 01:01 | |
17 | D4 | 8 | 28 | S3 | 100 | 01:00 | |
18 | D4 | 8 | 28 | S3 | 100 | 01:01 |
Zum Vergleich die Zeiten aus dem Beitrag davor:
Kopie Cronus-Mandant | NAV 2015 (in Sek.) | NAV 2016 mit Azure SQL (in Sek.) |
---|---|---|
1 | 61 | 177 |
2 | 48 | 175 |
3 | 51 | 171 |
4 | 61 | 173 |
5 | 56 | 180 |
Durchschnitt | 55 | 175 |
Hier aufbereitet als Chart:
Meine Meinung zu den Ergebnissen (und bitte bedenkt, dass ich hier ein vollständiges Benchmark von NAV 2016 habe, sondern wirklich nur den CRONUS-Mandanten kopiere und die Zeiten dazu messe):
Mehr DTUs = mehr Performance
Es gilt zumindest für NAV: Je mehr DTUs, desto besser. Das passt.
10x mehr DTUs nicht gleich 10x mehr Performance
Aber die Performance skaliert nicht linear. Doppelt so viele DTUs halbiert nicht die Wartezeit. Aber das ist in der Realität oft so: Ein Auto mit 1000 PS ist auch nicht 10x so schnell wie ein Auto mit 100 PS. Das muss man nur wissen.
100 DTUs gleicht etwa einer nicht optimierten SQL-Installation auf C:
Das erstaunt mich doch, weil ich glaube, dass eine SQL-Installation auf VM-Festplatten und dann auf der C:-Systempartition nicht die beste Leistung verspricht. Da habe ich von 100 DTUs (der dicksten Variante aus dem Standardlevel) mehr erwartet. So scheinen 100 DTUs für eine NAV-Produktiv-Umgebung eher ungeeignet, eher 1000 DTUs? Wäre eine SQL-Partition auf einer SSD in Azure die bessere Lösung?
CPU und RAM spielen zunächst eine untergeordnete Rolle
Die Gegenprobe mit der dicksten VM D4 (8 Kerne, 28 GB) und 10 DTUs brachten etwa die gleichen Ergebnisse wie mit der kleinsten VM (D1: (1 Kern, 3.5 GB) und 10 DTUs. Natürlich sollte man eine 100-User-Installation nicht auf einer D1 laufen lassen, aber zunächst scheint für NAV doch die DTU-Leistung der Flaschenhals zu sein.
Es sieht so aus, als gäbe es noch viel Luft für Verbesserungen im Zusammenspiel NAV 2016 + Azure SQL!