Performancetest NAV 5.00 Update 1 vs. NAV 5.00 SP1 (SQL)
18. März 2008 23:15
Hallo zusammen,
wie bereits im Titel zu lesen geht es hier darum, ob schon jemand Vergleiche zwischen NAV 5.00 und NAV 5.00 SP1 auf dem SQL Server durchgeführt hat und bereits Erfahrungen mit den Indexed Views die die SIFT Tables ersetzen werden vorliegen. Jörg?
Ich selbst habe heute einen kurzen und nicht repräsentativen Test auf meinem Notebook durchgeführt. Hier kam es nur auf Zeitunterschiede und nicht die Performance ansich an:
Für alle Artikel im CRONUS für alle Tage des Januar 2007 die Anzahl x Artikel ein- und anschließend ausgebucht. Jeweils die Lagerregulierung hinterher. Einen expliziten CALCSUMS Test werde ich morgen noch durchführen.
Bei diesen Vorgängen unterschieden sich die Clients im Sekundenbereich (bei ca. 50 Minuten um ca. 20 Sekunden) wobei auch mal der "alte" Client schneller war. Also bis hierher würde ich zumindest keine Beeinträchtigung der Performance verbuchen wollen. Interessant wird es sicher bei noch größeren Datenmengen. Das werde ich vielleicht nochmal prüfen.
Ingesamt bis dato also gleiche Performance.
Hat sonst noch jemand Erfahrungen (auch gern tiefgreifender)? Den Profiler hab ich nun z.B. noch nicht befragt.
wie bereits im Titel zu lesen geht es hier darum, ob schon jemand Vergleiche zwischen NAV 5.00 und NAV 5.00 SP1 auf dem SQL Server durchgeführt hat und bereits Erfahrungen mit den Indexed Views die die SIFT Tables ersetzen werden vorliegen. Jörg?
Ich selbst habe heute einen kurzen und nicht repräsentativen Test auf meinem Notebook durchgeführt. Hier kam es nur auf Zeitunterschiede und nicht die Performance ansich an:
Für alle Artikel im CRONUS für alle Tage des Januar 2007 die Anzahl x Artikel ein- und anschließend ausgebucht. Jeweils die Lagerregulierung hinterher. Einen expliziten CALCSUMS Test werde ich morgen noch durchführen.
Bei diesen Vorgängen unterschieden sich die Clients im Sekundenbereich (bei ca. 50 Minuten um ca. 20 Sekunden) wobei auch mal der "alte" Client schneller war. Also bis hierher würde ich zumindest keine Beeinträchtigung der Performance verbuchen wollen. Interessant wird es sicher bei noch größeren Datenmengen. Das werde ich vielleicht nochmal prüfen.
Ingesamt bis dato also gleiche Performance.
Hat sonst noch jemand Erfahrungen (auch gern tiefgreifender)? Den Profiler hab ich nun z.B. noch nicht befragt.
19. März 2008 11:26
Hi!
Nö, ich hatte leider noch keine Zeit um damit zu "spielen". Ich erwarte im Prinzip aber folgendes:
Durch die neuen "Indexes Views" wird im wesentlichen das Schreiben von Posten verbessert, da keine zusätzlichen Schreib-Transaktionen in SIFT Tabellen notwendig sind. Da im aktuellen Standard die SIFT Strukturen eh "Schrott" sind, sollte natürlich ein enormer Unterschied zwischen "Standard SIFT Tabelle" und "Standard Index View" dutlich werden. Hat man jedoch die "SIFT Tabellen" optimiert, wird dieser Unterschied eher marginal ausfallen.
Beim Lesen, so fürchte ich, wird zumindest bei großen Tabellen ein gegenteiliger Effekt auftreten: Ein "View" ist lediglich eine vordefinierte SELECT Anweisung, d.h. die neuen "SIFT Views" lesen direkt von der Postentabelle und aggregieren dabei. Unterstützt wird dies durch "View"-eignen Indexe. Aber auch diese Indizierung gelabgt irgendwann ans Ende, je größer die Postentabelle, desto größer die Indexe - auch die der Views - und damit wird die Leseleistung stetig abnehmen. Abhilfe kann nur eine Reduzierung der DS in der Postentabelle schaffen!
Hat man die SIFT Tabellen optimiert, d.h. man verwendet nur benötigte Buckets (genauers dazu in meinem Buch oder BLOG), dann denke ich, dass dies für die Leseleistung optimal ist:
Es ist eben schneller einen Aggregations-DS aus der SIFT Tabelle unmittelbar zu lesen, als mittelbar - via View - tausende von DS in der Postentabelle ...
Also, es geht wie so oft um "Lesen vs. Schreiben"...
Deshalb wäre mein Wunsch an MS, dass man selbts entscheiden kann, für welche Keys/Indexe welches SIFT Verfahren benutzt werden soll ...
Nö, ich hatte leider noch keine Zeit um damit zu "spielen". Ich erwarte im Prinzip aber folgendes:
Durch die neuen "Indexes Views" wird im wesentlichen das Schreiben von Posten verbessert, da keine zusätzlichen Schreib-Transaktionen in SIFT Tabellen notwendig sind. Da im aktuellen Standard die SIFT Strukturen eh "Schrott" sind, sollte natürlich ein enormer Unterschied zwischen "Standard SIFT Tabelle" und "Standard Index View" dutlich werden. Hat man jedoch die "SIFT Tabellen" optimiert, wird dieser Unterschied eher marginal ausfallen.
Beim Lesen, so fürchte ich, wird zumindest bei großen Tabellen ein gegenteiliger Effekt auftreten: Ein "View" ist lediglich eine vordefinierte SELECT Anweisung, d.h. die neuen "SIFT Views" lesen direkt von der Postentabelle und aggregieren dabei. Unterstützt wird dies durch "View"-eignen Indexe. Aber auch diese Indizierung gelabgt irgendwann ans Ende, je größer die Postentabelle, desto größer die Indexe - auch die der Views - und damit wird die Leseleistung stetig abnehmen. Abhilfe kann nur eine Reduzierung der DS in der Postentabelle schaffen!
Hat man die SIFT Tabellen optimiert, d.h. man verwendet nur benötigte Buckets (genauers dazu in meinem Buch oder BLOG), dann denke ich, dass dies für die Leseleistung optimal ist:
Es ist eben schneller einen Aggregations-DS aus der SIFT Tabelle unmittelbar zu lesen, als mittelbar - via View - tausende von DS in der Postentabelle ...
Also, es geht wie so oft um "Lesen vs. Schreiben"...
Deshalb wäre mein Wunsch an MS, dass man selbts entscheiden kann, für welche Keys/Indexe welches SIFT Verfahren benutzt werden soll ...
19. März 2008 11:58
Das waren theoretisch auch meine Gedanken. Ich gehe davon aus, dass mit wesentlich mehr Posten auch merkliche Unterschiede auftreten. Nur leider hat die Zeit gestern nicht ausgereicht um so viele Posten zu erzeugen um dann die Leseperformance für sich alleine zu prüfen. Vielleicht schaffe ich das ja in meinem Urlaub nächste Woche.
Vielleicht bekommen wir die Entscheidungsmöglichkeit noch bis zum Release. Aber ehrlich gesagt glaube ich nicht daran. Es ist schon schade, dass dieser krasse Einschnitt nicht wählbar ist und man "hoffen" muss, dass ein Umstieg auf SP1 keine Probleme in großen Datenbanken herbeiführt. Aber warten wir es ab. Ich melde mich sobald ich Millionen von Datensätzen in den Postentabellen hab
Vielleicht bekommen wir die Entscheidungsmöglichkeit noch bis zum Release. Aber ehrlich gesagt glaube ich nicht daran. Es ist schon schade, dass dieser krasse Einschnitt nicht wählbar ist und man "hoffen" muss, dass ein Umstieg auf SP1 keine Probleme in großen Datenbanken herbeiführt. Aber warten wir es ab. Ich melde mich sobald ich Millionen von Datensätzen in den Postentabellen hab
19. März 2008 12:36
Da ihr hier schon drüber diskutiert: Wo habt ihr das SP1 bezogen? Über PartnerSource wird nix angeboten und google spuckt auch nix aus, bis auf einige Neuerungen die im November 07 veröffentlicht wurden.
19. März 2008 14:20
Ich glaube, hier ist nicht SP1, sondern Update 1 gemeint.
Update 1 beinhaltet nur ein Update der fin.exe bzw. der finsql.exe (und anderen Systemobjekten), nicht aber der Datenbankobjekte.
Update 1 beinhaltet nur ein Update der fin.exe bzw. der finsql.exe (und anderen Systemobjekten), nicht aber der Datenbankobjekte.
19. März 2008 14:37
Nö ... wir meinen schon "Service Pack 1" für NAV 5.0 ... der wird z.Zt. in "Partner Source" nur angekündigt, doch haben einige "Auserwählte" - bestimmte Dynamics Partner und MVP 
- die Alpha- und Beta-Versionen schon vorab von MS erhalten ...
- die Alpha- und Beta-Versionen schon vorab von MS erhalten ...
19. März 2008 15:13
Achsoooooooo ... Naja, selbst wenn mein Brötchengeber zu diesem erlauchten Personenkreis gehört, würde ich es garantiert als letzte erfahren *g*
19. März 2008 16:03
Hmm, und wann kommt der Release? Wo gibts denn die Beta? Ich kann mir nicht vorstellen, dass mein Brötchengeber, welcher Top3 Microsoft Goldpartner für Dynamics Nav ist, übergangen worden ist.
19. März 2008 17:13
Naja vielleicht hat dein Brötchengeber diese Beta noch irgendwo in seinem Mailfach rummgammeln. Ich würd einfach mal freundlich fragen
19. März 2008 17:14
Auf die Größe kommt's nicht an
Ist eher eine Frage von "Relations" ...
MS hat den einen oder anderen Partner/MVP gefragt, ob man am Alpha/Beta-Test teilnehmen möchte - wer voluntiert hat, hat die entsprechenden Links zum Download etc. erhalten.
Die offizielle Seite ist hier: https://mbs.microsoft.com/partnersource/downloads/releases/MicrosoftDynamicsNAV50SP1.htm
Ist eher eine Frage von "Relations" ...
MS hat den einen oder anderen Partner/MVP gefragt, ob man am Alpha/Beta-Test teilnehmen möchte - wer voluntiert hat, hat die entsprechenden Links zum Download etc. erhalten.
Die offizielle Seite ist hier: https://mbs.microsoft.com/partnersource/downloads/releases/MicrosoftDynamicsNAV50SP1.htm
19. März 2008 17:14
Der endgültige Release von 5.0 SP1 ist - unter Vorbehalt - für April geplant. So hat man es mir bei Microsoft gesagt.
19. März 2008 17:28
@Natalie: Danke.
Naja, das Thema 5.00 SP1 kam nur heute kurz auf, weil der Kollege meinte, der Release für SP1 sei Anfang März gewesen. Mein Brötchengeber hat an den Betas an sich keine Interesse, sonst hätte der sie auch schon erhalten :)
Aber mir ging es ursprünglich umden echten Release vom SP1. Vielen Dank für den Link.
Gruß
Jan
Naja, das Thema 5.00 SP1 kam nur heute kurz auf, weil der Kollege meinte, der Release für SP1 sei Anfang März gewesen. Mein Brötchengeber hat an den Betas an sich keine Interesse, sonst hätte der sie auch schon erhalten :)
Aber mir ging es ursprünglich umden echten Release vom SP1. Vielen Dank für den Link.
Gruß
Jan
3. April 2008 10:35
So, wie angedroht nun mal das Ergebnis meines nicht representativen Tests:
Es gab 2 Datenbanken, Update 1 und SP1. Beide starteten mit 500MB Datenfilegröße, 250MB Logfile, automatische Vergrößerung um 500MB Daten, 250MB Log, Simple Logging.
Ein Report lief über eine Periode von einem Jahr (01.01.07..31.12.07) und buchte innerhalb dieser Periode für jeden Tag, jede Location und jede Variante zwischen 1 und 50 Artikeln ein, anschließend aus, dann wurde die Regulierung aufgerufen.
Jeweils nach 2 Wochen wurde ein weiterer Report aufgerufen der für jeden Artikel 100 Mal vom 01.01.07-01.01.07, 01.01.07-02.01.07, 01.01.07-03.01.07 ... 01.01.07-31.12.07 einige Summen kalkulierte:
Daraus ergab sich folgendes Zeitverhalten:
Auf Update 1 lief der gesamte Vorgang 16:33 Stunden, auf dem SP1 dann 15:52 Stunden. Während des SP1 Laufs wurde noch einige Stunden parallel gearbeitet.
Ich lasse die Daten mal so stehen ohne sie groß zu kommentieren. Sieht aber bisher noch relativ linear aus. Das mag sich ändern, wenn die "mehrere Millionen Posten"-Grenze überschritten wird.
Es gab 2 Datenbanken, Update 1 und SP1. Beide starteten mit 500MB Datenfilegröße, 250MB Logfile, automatische Vergrößerung um 500MB Daten, 250MB Log, Simple Logging.
Ein Report lief über eine Periode von einem Jahr (01.01.07..31.12.07) und buchte innerhalb dieser Periode für jeden Tag, jede Location und jede Variante zwischen 1 und 50 Artikeln ein, anschließend aus, dann wurde die Regulierung aufgerufen.
Jeweils nach 2 Wochen wurde ein weiterer Report aufgerufen der für jeden Artikel 100 Mal vom 01.01.07-01.01.07, 01.01.07-02.01.07, 01.01.07-03.01.07 ... 01.01.07-31.12.07 einige Summen kalkulierte:
- Code:
ValueEntry.RESET;
ValueEntry.SETCURRENTKEY("Item No.", "Posting Date");
ValueEntry.SETRANGE("Item No.", ItemNo);
ValueEntry.SETRANGE("Posting Date", StartDate, EndDate);
ValueEntry.CALCSUMS("Cost Amount (Expected)", "Cost Amount (Actual)", "Purchase Amount (Expected)",
"Purchase Amount (Actual)", "Sales Amount (Expected)", "Sales Amount (Actual)");
ValueEntry.RESET;
ValueEntry.SETCURRENTKEY("Item No.", "Valuation Date", "Location Code", "Variant Code");
ValueEntry.SETRANGE("Item No.", ItemNo);
ValueEntry.SETRANGE("Valuation Date", StartDate, EndDate);
IF VariantCode <> '' THEN BEGIN
ValueEntry.SETRANGE("Variant Code", VariantCode);
END;
ValueEntry.CALCSUMS("Cost Amount (Expected)", "Cost Amount (Actual)",
"Cost Amount (Expected) (ACY)", "Cost Amount (Actual) (ACY)", "Item Ledger Entry Quantity");
Daraus ergab sich folgendes Zeitverhalten:
- Code:
No. of VE SP1 UP1
340 2,427 2,891
31874 18,623 25,201
63258 38,481 48,048
94706 58,636 76,656
126130 82,554 106,672
157514 109,250 139,418
188922 137,219 171,543
220362 163,093 216,022
251802 197,063 326,556
283202 231,437 347,037
314618 269,621 361,306
346002 309,031 420,923
377378 348,486 466,254
408810 392,038 495,285
440210 468,790 673,906
471610 522,260 677,771
502994 576,262 772,784
534386 635,637 790,631
565802 724,826 849,507
597226 760,249 919,010
628610 827,657 1005,258
660026 941,986 1174,897
691426 953,096 1128,978
722858 1018,890 1302,496
754290 1170,181 1332,575
785714 1276,570 1447,882
817130 1373,275 1576,386
===========================
13607,638 16855,893
Auf Update 1 lief der gesamte Vorgang 16:33 Stunden, auf dem SP1 dann 15:52 Stunden. Während des SP1 Laufs wurde noch einige Stunden parallel gearbeitet.
Ich lasse die Daten mal so stehen ohne sie groß zu kommentieren. Sieht aber bisher noch relativ linear aus. Das mag sich ändern, wenn die "mehrere Millionen Posten"-Grenze überschritten wird.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
5. April 2008 10:03
Weitere interessante Informationen zum UP1/SP1-Vergleich finden sich im Microsoft Dynamics NAV Sustained Engineering Team Blog. Zum einen My experiences with Microsoft Dynamics NAV 5.0 SP1 und zum Zweiten dieses: SQL Pre-processing in Microsoft Dynamics NAV 5.0 SP1.
6. April 2008 12:29
Ich habe soeben die Performancetests mit einer unter 4.03 hoch optimierten DB mit 430Gb Daten aufgenommen. wir haben über 850 lagerorte verteilt ca. 110 mill Transaktionen (T32) und ca. 120 mill T5802.
in der T32 waren nur ein Sift mit 4 Buckets gepflegt (Artikel, Artikel-Lagerort,Artikel-Lagerort-Bewegtyp, +Tag).
Die Konvertierung hat auf einer Highend SAN ca. 2 Stunden benötigt!!!, Die Anwortzeiten sind nach der Konvertierung ohne zusätzlichen Eingriff überraschend SEHR gut, sowohl die calc. der Lagerbestände, welche ja nun die Summe aller Details ist im Vergleich zur alten SIFT Struktur 1 Record. Über alles gesehen ist die v5 mit SP1 nach aktuellen Messungen ca. 20% performanter, teilweise sogar um die 50%. Im jetzigen Moment kann ich von meiner Seite keine Nachteile bei den Antwortzeiten feststellen. Wir haben sämtliche Test mit parallel laufenden Jobs vorgenommen, welche auf der einen Seite hohe Leseraten, auf der anderen Seite hohe Schreibfrequenz haben. Resüme: Empfehlenswert
in der T32 waren nur ein Sift mit 4 Buckets gepflegt (Artikel, Artikel-Lagerort,Artikel-Lagerort-Bewegtyp, +Tag).
Die Konvertierung hat auf einer Highend SAN ca. 2 Stunden benötigt!!!, Die Anwortzeiten sind nach der Konvertierung ohne zusätzlichen Eingriff überraschend SEHR gut, sowohl die calc. der Lagerbestände, welche ja nun die Summe aller Details ist im Vergleich zur alten SIFT Struktur 1 Record. Über alles gesehen ist die v5 mit SP1 nach aktuellen Messungen ca. 20% performanter, teilweise sogar um die 50%. Im jetzigen Moment kann ich von meiner Seite keine Nachteile bei den Antwortzeiten feststellen. Wir haben sämtliche Test mit parallel laufenden Jobs vorgenommen, welche auf der einen Seite hohe Leseraten, auf der anderen Seite hohe Schreibfrequenz haben. Resüme: Empfehlenswert
6. April 2008 15:49
Hallo Erich,
danke für das sehr interessante Statement und die Tests. Ich überlege das SP1 bei einem Kunden mit 120GB DB einzusetzen, da sind solche Informationen extrem hilfreich.
Kannst du noch ein paar Informationen zu der Umgebung geben? SQL Server Build, Hardware?
danke für das sehr interessante Statement und die Tests. Ich überlege das SP1 bei einem Kunden mit 120GB DB einzusetzen, da sind solche Informationen extrem hilfreich.
Kannst du noch ein paar Informationen zu der Umgebung geben? SQL Server Build, Hardware?
6. April 2008 16:37
Hallo SilverX
Der SQL2005 Build ist 3228 = Hotfixpackage 6 (nur Trace Flage 4616 gesetzt) 64 Bit, 64GB RAM, davon 60 für SQL.
Aber die Prozessoren langweilen sich mit NAV sowieso immer. Wichtig ist prio der Memory und die disc. Die Disc ist eben mechanisch bedingt der langsamste Teil an jeder Hardware.
Die prod. DB ist auf 16 mounts verteilt, 1 mount je prozessor (4 quad Core), die mounts sind mit 32 GB konfiguriert und je mount ist ein File a 30 GB definiert. Die Log Files liegen auf einem eigenen Drive.
Wir haben noch eine 2 DB mit ca. 800 GB, dort haben wir anders indiziert, da optmiert für Auswertungen. Hier gilt aber das gleiche wie für die "kleine" DB
Die SAN ist mit 9 Discgruppen konfiguriert, ein Mount bezieht sich immer auf eine bestimmte Discgruppe.
Die Anzahl Prozessoren und die Anzahl drives bzw. mounts sollten immer im Gleichklang sein. Die Grundregel ist, immer ein vielfaches der genutzten Prozessoren an Mounts zu haben, minimal so viele, wie Du Prozessoren hast. Alle Files sollten von Anfang an gleich gross sein, die Files liegen alle in der gleichen Filegruop, der SQL Server verteilt dann die Daten schön über die einzelenen Files.
Wenn bekannt ist, dass die DB schnell wächst, man aber noch nicht so viel Discspace hat, dann definiert man 2 oder mehr kleinere Files je mount und wenn später mehr discspace in Form von mehr mounts zur Verfügung steht, verschiebt man die Files aus den bestehenden mounts in die neuen mounts und vergrössert dann alle gleichzeitig. Der Killer ist, wenn man einzelne Files ergänzt, dann nutzt der SQL Server nur dieses eine File für neue Daten bis es gleich gefüllt ist, wie die alten files und beginnt erst dann wieder auf alle Files gleichmässig zu verteilen.
Der Write Cache der SAN ist dynamisch opimiert, aber da wissen die SAN Spezialisten, je nach Hersteller, mehr. Ist nicht mein Ding.
Wie bereits geschrieben und auch im Blog des Engineering Team dokumentiert bringt das SP1 sowohl bei Standard als auch bei optimierten Prozeduren etwas. Bei der optimierten Variante war ich doch überrascht, dass es so gut geht. Der Performancegewinn ist wahrscheinlich bei einer Standard DB grösser als bei einer optimierten DB, Bezüglich Datenbankgrösse hat sich bei mir kaum etwas bewegt, ist nur um 5% runter.
Der SQL2005 Build ist 3228 = Hotfixpackage 6 (nur Trace Flage 4616 gesetzt) 64 Bit, 64GB RAM, davon 60 für SQL.
Aber die Prozessoren langweilen sich mit NAV sowieso immer. Wichtig ist prio der Memory und die disc. Die Disc ist eben mechanisch bedingt der langsamste Teil an jeder Hardware.
Die prod. DB ist auf 16 mounts verteilt, 1 mount je prozessor (4 quad Core), die mounts sind mit 32 GB konfiguriert und je mount ist ein File a 30 GB definiert. Die Log Files liegen auf einem eigenen Drive.
Wir haben noch eine 2 DB mit ca. 800 GB, dort haben wir anders indiziert, da optmiert für Auswertungen. Hier gilt aber das gleiche wie für die "kleine" DB
Die SAN ist mit 9 Discgruppen konfiguriert, ein Mount bezieht sich immer auf eine bestimmte Discgruppe.
Die Anzahl Prozessoren und die Anzahl drives bzw. mounts sollten immer im Gleichklang sein. Die Grundregel ist, immer ein vielfaches der genutzten Prozessoren an Mounts zu haben, minimal so viele, wie Du Prozessoren hast. Alle Files sollten von Anfang an gleich gross sein, die Files liegen alle in der gleichen Filegruop, der SQL Server verteilt dann die Daten schön über die einzelenen Files.
Wenn bekannt ist, dass die DB schnell wächst, man aber noch nicht so viel Discspace hat, dann definiert man 2 oder mehr kleinere Files je mount und wenn später mehr discspace in Form von mehr mounts zur Verfügung steht, verschiebt man die Files aus den bestehenden mounts in die neuen mounts und vergrössert dann alle gleichzeitig. Der Killer ist, wenn man einzelne Files ergänzt, dann nutzt der SQL Server nur dieses eine File für neue Daten bis es gleich gefüllt ist, wie die alten files und beginnt erst dann wieder auf alle Files gleichmässig zu verteilen.
Der Write Cache der SAN ist dynamisch opimiert, aber da wissen die SAN Spezialisten, je nach Hersteller, mehr. Ist nicht mein Ding.
Wie bereits geschrieben und auch im Blog des Engineering Team dokumentiert bringt das SP1 sowohl bei Standard als auch bei optimierten Prozeduren etwas. Bei der optimierten Variante war ich doch überrascht, dass es so gut geht. Der Performancegewinn ist wahrscheinlich bei einer Standard DB grösser als bei einer optimierten DB, Bezüglich Datenbankgrösse hat sich bei mir kaum etwas bewegt, ist nur um 5% runter.