Frage: 🐌🐌🐌JTL-Wawi 1.9 - Wie schnell öffnet sich bei euch die Auftragsansicht?

[Powalowski]

Bei uns dauert das bloße Öffnen eines Auftrags auf jeden Fall über eine Sekunde, im Schnitt 2-3 Sekunden würde ich sagen. Das ist im Bereich eines Bugs🪲
Frage: Wie schnell geht es bei euch?

SQL Server 2022, Bare Metal im Container, 12 Cores, 24Gb Ram

Es sei dazu gesagt, dass wir einiges an Eigenen Feldern etc. haben + eine Menge Workflows (ich wüsste aber nicht, dass welche ablaufen beim Öffnen)

Ich denke Wunsch Nummer 1 auf der Wunschliste sollte sein: MEHR PERFORMANCE
Wie ist da bei euch die Stimmung? Oder haben wir irgendwo eine schlechte Konfiguration, von der ich nichts weiß.

Ich verstehe nicht, wieso ein Produktionsplaner gebaut wird aber die Performance so dermaßen gruselig ist.

 

[Powalowski]

Ich könnte wetten, dass als nächstes das Buzzword KI mit Trompeten und Fanfaren eingebaut wird, während die Basics weiterhin krebsen.
HiDPI ist übrigens auch immer noch schlecht.

 

[John]

SQL Server 2022, Bare Metal im Container, 12 Cores, 16Gb Ram

12 Cores sagt ja erstmal nicht viel, solange Du nicht sagst, ob das Core-I oder Xeons und welche Generation
Was für ein SQL Server? Express oder Standard und welches OS darunter.
Was für Festplatten?

Unabhängig von den Details halte ich 16GB für sehr, sehr, sehr wenig RAM

Deine 1-2 Sekunden hast Du dann direkt auf dem Server gemessen?
Wie? Direkt nach dem Wawi Start oder nachdem bereits schonmal ein anderer Auftrag geöffnet worden ist?


Nachtrag.
Ich hab mal eben direkt auf dem Server bei uns probiert.
Wawi 1.8, gefühlt im unteren 2 Sekunden Bereich.
Die Ursache dafür muss nicht unbedingt auf SQL Ebene liegen. Das Fenster, das da in DotNet geladen wird, hat eine sehr große Menge an Steuerlemente. Die laden dauert.

 

[mAze]

12 Cores sagt ja erstmal nicht viel, solange Du nicht sagst, ob das Core-I oder Xeons und welche Generation
Was für ein SQL Server? Express oder Standard und welches OS darunter.
Was für Festplatten?

Unabhängig von den Details halte ich 16GB für sehr, sehr, sehr wenig RAM

Deine 1-2 Sekunden hast Du dann direkt auf dem Server gemessen?
Wie? Direkt nach dem Wawi Start oder nachdem bereits schonmal ein anderer Auftrag geöffnet worden ist?


Nachtrag.
Ich hab mal eben direkt auf dem Server bei uns probiert.
Wawi 1.8, gefühlt im unteren 2 Sekunden Bereich.
Die Ursache dafür muss nicht unbedingt auf SQL Ebene liegen. Das Fenster, das da in DotNet geladen wird, hat eine sehr große Menge an Steuerlemente. Die laden dauert.

Ich muss mal kurz dazwischen grätschen. Wieviel Cores kann die JTL Wawi überhaupt nutzen? Ist denn der Unterschied zwischen einen aktuellen Intel Xeon E-2468 Prozessor 2.6 GHz (8 Cores) und einen I9 mit 16 oder 24 Core so groß?

Mit freundlichen Grüßen

 

[recent.digital]

Wenn du den SQL Standard nutzt, kann das einen Unterschied machen. In der Express-Edition macht es keinen Unterschied, weil es sowieso Limitierungen gibt.

 

[mAze]

Wenn du den SQL Standard nutzt, kann das einen Unterschied machen. In der Express-Edition macht es keinen Unterschied, weil es sowieso Limitierungen gibt.

Wenn man es wirklich soweit treibt sollte man aber ohnehin mindestens Windows Server Standard mit einer 16 oder 24 Core Lizenz verwendet werden. Essentials ist ja auf 10 Cores beschränkt und Windows10 oder 11 ist dafür theoretisch nicht erlaubt.

 

[mh1]

Ich muss mal kurz dazwischen grätschen. Wieviel Cores kann die JTL Wawi überhaupt nutzen?

Das weiß ich zwar auch nicht, aber der SQL-Server könnte ab Standard die 12 Cores schon ganz gut nutzen. Die Express ist eh auf 4 Cores beschränkt.

Eine interessante Größe ist auch immer die Anzahl der Verbindungen auf den SQL-Server. Hierbei ist dann u.a. die Speichergröße für den Buffer Pool interessant.
Bei Express wäre dieser aber eh auf 1410 MB beschränkt.

Die Clients über Kabel anzuschließen bringt bei Datenbankanwendungen oft einen erstaunlichen Schub (also gegenüber WLAN mein ich).

Bei allen Datenbankanwendungen (also nicht nur bei JTL Wawi) liegt heutzutage der Performance Zauber aber eher darin, wie die Daten abgefragt werden (also im Prinzip die SQL Befehle die der Client an den Server schickt) und, wie ein Vorredner schon sagte, wie wann welche Daten ins GUI reingebastelt werden.

 

[mAze]

Das weiß ich zwar auch nicht, aber der SQL-Server könnte ab Standard die 12 Cores schon ganz gut nutzen. Die Express ist eh auf 4 Cores beschränkt.

Eine interessante Größe ist auch immer die Anzahl der Verbindungen auf den SQL-Server. Hierbei ist dann u.a. die Speichergröße für den Buffer Pool interessant.
Bei Express wäre dieser aber eh auf 1410 MB beschränkt.

Die Clients über Kabel anzuschließen bringt bei Datenbankanwendungen oft einen erstaunlichen Schub (also gegenüber WLAN mein ich).

Bei allen Datenbankanwendungen (also nicht nur bei JTL Wawi) liegt heutzutage der Performance Zauber aber eher darin, wie die Daten abgefragt werden (also im Prinzip die SQL Befehle die der Client an den Server schickt) und, wie ein Vorredner schon sagte, wie wann welche Daten ins GUI reingebastelt werden.

kann denn SQL Server Standard z.b 16 Cores oder die 24 Cores nutzen auch wenn Windows Server 2022 Essentials was nur max. 10 Cores unterschützt verwenden ?

 

[Powalowski]

Ich habe mittlerweile eine Stage geclont und je nach verwendeter Datenbank geht es unterschiedlich schnell. Die anderen Sachen (Nicht Auftrag öffnen) gehen auf der anderen Datenbank, die ja Production und mehr performance hat erwartungsgemäß schneller. Verkehrte Welt

@mAze @mh1 @recent.digital

Frage: Wie schnell geht es bei euch?

 

[mh1]

kann denn SQL Server Standard z.b 16 Cores oder die 24 Cores nutzen auch wenn Windows Server 2022 Essentials was nur max. 10 Cores unterschützt verwenden ?

Nein, wenn Windows Essential sagt, es gibt zehn Cores, dann sieht auch jede Software, die auf diesem Betriebssystem läuft nur zehn Cores

Um dem SQL die 24 Cores zur Verfügung zu stellen brauchts also den Standard Windows Server. Aber bei 24 ist dann auch Schluss, denn SQL Standard ist auf 24 Cores limitiert.

Da @Powalowski aber im anderen Thread geschrieben hat, dass er den SQL auf einem Rechner mit mehr als 32 GB RAM hat und hier sinds plötzlich 16 GB, wissen wir doch eh nicht so genau was denn letzlich als Hard-/Software eingesetzt wird.

 

[Powalowski]

Nein, wenn Windows Essential sagt, es gibt zehn Cores, dann sieht auch jede Software, die auf diesem Betriebssystem läuft nur zehn Cores

Um dem SQL die 24 Cores zur Verfügung zu stellen brauchts also den Standard Windows Server. Aber bei 24 ist dann auch Schluss, denn SQL Standard ist auf 24 Cores limitiert.

Da @Powalowski aber im anderen Thread geschrieben hat, dass er den SQL auf einem Rechner mit mehr als 32 GB RAM hat und hier sinds plötzlich 16 GB, wissen wir doch eh nicht so genau was denn letzlich als Hard-/Software eingesetzt wird.

Haha, war ja klar, dass jemand diese Nadel im Heuhaufen findet. Das ist ein Container, dem mittlerweile im Zuge meiner Experimente 24gb Ram zugewiesen sind.
Der Rechner selbst hat 128gb oder sowas.
@mh1 Wie schnell geht es bei dir?

 

[mAze]

Nein, wenn Windows Essential sagt, es gibt zehn Cores, dann sieht auch jede Software, die auf diesem Betriebssystem läuft nur zehn Cores

Um dem SQL die 24 Cores zur Verfügung zu stellen brauchts also den Standard Windows Server. Aber bei 24 ist dann auch Schluss, denn SQL Standard ist auf 24 Cores limitiert.

Da @Powalowski aber im anderen Thread geschrieben hat, dass er den SQL auf einem Rechner mit mehr als 32 GB RAM hat und hier sinds plötzlich 16 GB, wissen wir doch eh nicht so genau was denn letzlich als Hard-/Software eingesetzt wird.

oder eben Windows 10 oder 11 Pro

 

[Powalowski]

oder eben Windows 10 oder 11 Pro

@mAze Windows ist sowieso das allerbeste

 

[recent.digital]

Es wurde soeben eine neue 1.9. veröffentlich mit einigen Performance-Verbesserungen; wer möchte zu erst?

 

[mAze]

@mAze Windows ist sowieso das allerbeste

du meinst das "normale" Windows ? 🧐

 

[Powalowski]

du meinst das "normale" Windows ? 🧐

Windows, einfach nur Windows in allen Formen und Farben.

 

[mh1]

Ich habe mittlerweile eine Stage geclont und je nach verwendeter Datenbank geht es unterschiedlich schnell. Die anderen Sachen (Nicht Auftrag öffnen) gehen auf der anderen Datenbank, die ja Production und mehr performance hat erwartungsgemäß schneller. Verkehrte Welt

@mAze @mh1 @recent.digital

Frage: Wie schnell geht es bei euch?

Ich habe mir jetzt tatsächlich mal die Mühe gemacht, das Öffnen eines umfangreichen Auftrages zu stoppen. War ganz schön schwierig und ich hab es ein paarmal mit verschiedenen Aufträgen gemacht. Es dauerte aber immer so zwischen 0,5 s und 0,8 s. Solche Werte sind aber immer stark davon abhängig, was auf der Datenbank grad los ist und natürlich auch von dem was grundsätzlich im Netz los ist.

Oben hast du geschrieben, dass du den SQL-Server auf Bare Metal hast. Jetzt schreibst du, das du etwas geclont hast. Oben wird aber auch noch "im Container" genannt. Was denn nun?
Vielleicht betreibst du also einen SQL-Server im Docker oder in einer VM. Hast du dort die Netzwerkverbindungen richtig eingestellt. Denn das ist nicht ohne und ich habe schon viele fragwürdige Installationen gesehen.

Wurde denn zusätzlich zum Update der Wawi auch noch etwas anderes im LAN verändert. Da kann alles interessant werden. Auch z.b. ein neuer Drucker im Sekretariat.

 

[John]

Ich finde das auch eine sehr subjektive Diskussion.

Ja, Schwuppdizität von Software ist schön.
Und die Wawi ist nicht immer so schwuppsig, wie man das als Windows-Animations-Abschalter, der sich einbildet, dass Windows 2000 Optik sowieso am schnellsten war und der ich auch bin gerne hätte.

Aber was macht das im Betriebsalltag aus?
Öffnet man tatsächlich 1000 Aufträge am Tag? Wenn ja, wie lange verbringt man dann mit der Bearbeitung der Aufträge im Verhältniss zum Öffnen der Aufträge? Und wenn tatsächlich so viele Aufträge händisch geöffnet werden müssen, wieso bekommt man das nicht besser weg automatisiert?

Fragen über Fragen.
Wenn die Beschwerde über langsamen Ausgabe/Auslieferungsprozesse bestünde, der bereits durchautomatisiert ist, könnte ich das eher nachvollziehen als Aufträge öffnen...

 

[Powalowski]

Ich habe mir jetzt tatsächlich mal die Mühe gemacht, das Öffnen eines umfangreichen Auftrages zu stoppen. War ganz schön schwierig und ich hab es ein paarmal mit verschiedenen Aufträgen gemacht. Es dauerte aber immer so zwischen 0,5 s und 0,8 s. Solche Werte sind aber immer stark davon abhängig, was auf der Datenbank grad los ist und natürlich auch von dem was grundsätzlich im Netz los ist.

Oben hast du geschrieben, dass du den SQL-Server auf Bare Metal hast. Jetzt schreibst du, das du etwas geclont hast. Oben wird aber auch noch "im Container" genannt. Was denn nun?
Vielleicht betreibst du also einen SQL-Server im Docker oder in einer VM. Hast du dort die Netzwerkverbindungen richtig eingestellt. Denn das ist nicht ohne und ich habe schon viele fragwürdige Installationen gesehen.

Wurde denn zusätzlich zum Update der Wawi auch noch etwas anderes im LAN verändert. Da kann alles interessant werden. Auch z.b. ein neuer Drucker im Sekretariat.

Danke! Das war wirklich hilfrein, 500ms wäre ja schon mal was! Bei uns schwankt es einfach nur abartig. Ich habe auch die Queries geloggt und da ist kein ausreißer dabei. Ich werde das im Staging gegenprüfen aber aus meiner sicht wirkt nicht die DB lahm!

• Mit Bare Metal meinte ich im Container ohne VM, das sage ich da ja im Vergleich die meisten innerhalb einer Virtualisierung auf Windows oder direkt im Windows Server laufen
  => ich will Diskussionen vermeiden, weil ich weiß, dass die Leute zu Schnappatmung neigen, wenn man nur ein bisschen abweicht im Deployment und Kommentare wie: "Benutz die Windows Gui, so wie supported bla bla" wollt ich mir sparen.
• Es läuft so: Docker, auf Debian im LXC mit 12 Kernen, Standard, 24gb RAM zugewiesen, als wir damals auf das Setup gewechselt sind, war es wie ein Aufatmen der Geschwindigkeit
  [NACHTRAG]: da steht doch SQL Server 2022, Bare Metal im Container, 12 Cores, 24Gb Ram (hab den Ram aktualisiert für die Spitzfindigen).
• Traffic geht komplett lokal über Firewall VM, die auf der gleichen Maschine virtualisiert ist
  => Netzwerk habe ich zwischenzeitig mal umgebogen auf eine zweite Bridge, einfach um unerwarteten Schluckauf in dem Bereich auszuschließen. Bleibt gleich.

Ich verstehe, dass man immer erstmal Basisfehler unterstellt aber dann wäre das Setup mit 1.5 nicht jahre lang perfekt gelaufen.

Für die Anzweifler der Datenbank: Hier sieht man im Mitschnitt, das vom ersten Query bis zum letzten 283ms liegen und kein Query irgendwie ausreißt, alle schön hintereinander weg.
Wie sind eure Timings? Ich sag mal so: mit 500ms gesamt würden wir auch schon besser arbeiten können!

 

[Powalowski]

Ich finde das auch eine sehr subjektive Diskussion.

Ja, Schwuppdizität von Software ist schön.
Und die Wawi ist nicht immer so schwuppsig, wie man das als Windows-Animations-Abschalter, der sich einbildet, dass Windows 2000 Optik sowieso am schnellsten war und der ich auch bin gerne hätte.

Aber was macht das im Betriebsalltag aus?
Öffnet man tatsächlich 1000 Aufträge am Tag? Wenn ja, wie lange verbringt man dann mit der Bearbeitung der Aufträge im Verhältniss zum Öffnen der Aufträge? Und wenn tatsächlich so viele Aufträge händisch geöffnet werden müssen, wieso bekommt man das nicht besser weg automatisiert?

Fragen über Fragen.
Wenn die Beschwerde über langsamen Ausgabe/Auslieferungsprozesse bestünde, der bereits durchautomatisiert ist, könnte ich das eher nachvollziehen als Aufträge öffnen...

Wenn dir das zu subjektiv ist, dann schreib einfach deine Messzahl.
Wir bearbeiten Aufträge und alles über 500ms ist 🐌🐌🐌

Es ist keine Diskussion, sondern eine Frage.