Neu Diagramm bei Statistik deaktivieren!

[manuel767]

Hallo Zusammen,

leider hängt sich bei relativ aufwendigen Auswertungen unserer JTL-Wawi auf dem Server auf. (Verkaufte Menge je Monat aller Artikel im letzten Jahr) Ich denke, das liegt an der Erstellung des Diagrammes. Leider hab ich noch keine Möglichkeit gefunden, die Erstellung des Diagramms zu deaktivieren. Hat da jemand eine Lösung?

Danke Lg Manuel

 

[ToJo]

Hallo,

Deine Auswertung ist zu komplex! Das kann die Wawi so nicht darstellen und würde es Dir nach dem Rechnen auch mitteilen! Diagramm hin oder her

Ich habe das bei mir nun auch mal so gemacht und alle Artikel für dieses Jahr ausgewertet, es ging mit 3705 Artikeln und 16370 Verkäufen noch durch, aber die Wawi
wird lahm und nur der Export per csv brachte die ganze Liste zum Vorschein!

Daher würde ich empfehlen nach Warengruppe / Kategorie auszuwerten und / oder den Zeitraum mal entsprechend verkleinern um mal zu sehen wo der Server noch mitspielt....

Schönen Gruß
Torsten

 

[sebjo82]

Hallo,

Deine Auswertung ist zu komplex! Das kann die Wawi so nicht darstellen und würde es Dir nach dem Rechnen auch mitteilen! Diagramm hin oder her

Ich habe das bei mir nun auch mal so gemacht und alle Artikel für dieses Jahr ausgewertet, es ging mit 3705 Artikeln und 16370 Verkäufen noch durch, aber die Wawi
wird lahm und nur der Export per csv brachte die ganze Liste zum Vorschein!

Daher würde ich empfehlen nach Warengruppe / Kategorie auszuwerten und / oder den Zeitraum mal entsprechend verkleinern um mal zu sehen wo der Server noch mitspielt....

Schönen Gruß
Torsten

Der Server ist in der Regel nicht das Problem. Lässt man diese enorm rechenintensiven Queries direkt auf dem Server laufen ohne die Wawi als Schnittstelle, funktioniert das recht fix. Ich verstehe ehrlich gesagt nicht wo dieser Leistungsverlust herkommt (lokale Instanz ist etwas schneller als Hosting - zumindest in meinem Fall). Nehmt mal die Ameise und lasst euch etwas in eine .csv schreiben. So viele Zeilen wie möglich, damit der Unterschied deutlich wird. Dann versucht ihr denselben Output via reinem SQL im SSMS als .csv abzulegen. Dann fragt man sich: hä? Während die Ameise läuft, kann man hingehen Kaffee machen, Kuchen essen, Kaffee abkühlen lassen, in Ruhe austrinken, neuen Kaffee ansetzen, zurück an den Arbeitsplatz gehen. SSMS ist fertig bevor man überhaupt aufgestanden ist

 

[MichaelH]

Das Problem ist das Füllen des Grids zur Anzeige ... und ggf. auch die grafische Anzeige, das sind Objekte welche mit der Masse der Daten befüllt werden, auch wenn die Anzeige gar keinen Sinn mehr ergibt.

-> Hier wäre es von Vorteil wenn JTL eine Option schaffen würde das Ergebnis gleich als CSV exportieren zu können.

 

[sebjo82]

Ich glaube nicht, dass das Zeichnen von ein paar Linien und das Befüllen einer Tabelle derart viel Rechenleistung braucht, dass die Operation abbricht. Irgendwas ist mit der Wawi/ Ameise nicht in Ordnung. Wäre interessant zu erfahren warum das so ist, wir schauen hier ja nur auf eine Black-Box. Nehmt als Beispiel einfach mal eine datenintensive Webseite und vergleicht die Performance in reinem Daten-Output und Darstellungs-Aufbereitung. Ein gutes Beispiel (können viele vielleicht nichts mit anfangen) ist warcraftlogs.com: unendlich mehr Daten zu filtern und zu aggregieren und graphisch viel aufwendiger, aber Performance wovon man in der Wawi nur träumen kann. An der Menge an Artikeln und Aufträgen kann es auch nicht wirklich liegen, eine frische Wawi mit sagen wir 10 Artikeln und 1000 Aufträgen ist schon langsam

 

[MichaelH]

Aha, du willst also die komplette WAWI auf Massendatenverarbeitung optimieren lassen ?
Gute Idee, wird sofort umgesetzt.

Nein, ein Grid ist ein eigenes Objekt, mit eigener Logik und nicht von JTL programmiert und je nachdem wie das Ding gemacht ist, geht es sehr wohl in die Knie. Und es hat auch so was wie einen Verschiebebalken an der rechten Seite der bei dir ggf. fast endlos wird. Die Performancelast für das Ding entsteht am Frontend und nicht am Server und ich würde sogar behaupten zu einem Teil in der Grafikkarte.

 

[sebjo82]

Aha, du willst also die komplette WAWI auf Massendatenverarbeitung optimieren lassen ?

Ist das nicht ein Kerngebiet einer Wawi? ...
Die Queries selber sind ja nichtmal das Problem. Wie schon gesagt, lässt man diese im SSMS laufen, spuckt dieses einem das Ergebnis sofort aus (auf Wunsch auch in unter einer Sekunde in eine .csv). Warum macht die Ameise/die Wawi aus <1s ein paar Minuten?

Die Performancelast für das Ding entsteht am Frontend und nicht am Server und ich würde sogar behaupten zu einem Teil in der Grafikkarte.

Ich merke keinen Performance unterschied zwischen einem Client auf dem Arbeitslaptop mit iGPU oder dem Standrechner mit dGPU. Kann also nicht wirklich an der Grafikkarte liegen 5 Linien zu zeichnen

 

[MichaelH]

Nein, eine WAWI bearberitet primär 1 Kunde, 1 Artikel und 1 Auftrag.
Was du meinst wäre ein optimiertes Statsitik-Modul mit Cubes zur optimierten Auswertung von Massendaten durch vorgefertigte Zugriffspfade.

Und die Ameise beherrscht beliebige Datenselektion mit bis zu allen Feldern, daher werden die SQL dynamisch zusammengestoppelt und können nie optimiert sein.

Wenn das Grid keine Optimierung für einen Grafikkartentyp enthält, dann ist die Art der Grafikkarte ziemlich egal, ganz anders als bei deinem Lieblingsgame ...

 

[sebjo82]

Und die Ameise beherrscht beliebige Datenselektion mit bis zu allen Feldern, daher werden die SQL dynamisch zusammengestoppelt und können nie optimiert sein.

Eine nicht-optimierte Query macht also aus einem Bruchteil einer Sekunde ein paar Minuten oder sogar Stunden? Während SSMS in einer Sekunde gut 30000 Datensätze ausgespuckt hat, schafft die Ameise 100 (beides läuft lokal und auf derselben Instanz).

 

[MichaelH]

Klar, statt 30.000 pro Sekunde können das dann 30 pro Sekunde werden, denn gelesene Datensätze hat nichts mit selektieren Datensätzen zu tun.
Ein nicht optimiertes SQL liest ggf. 10.000 Datensätze pro Sekunde ein um 1 Satz auszugeben.
Heißt es werden Millionen von Datensätzen gelesen um 1000 auszugeben.

 

[sebjo82]

Klar, statt 30.000 pro Sekunde können das dann 30 pro Sekunde werden, denn gelesene Datensätze hat nichts mit selektieren Datensätzen zu tun.
Ein nicht optimiertes SQL liest ggf. 10.000 Datensätze pro Sekunde ein um 1 Satz auszugeben.
Heißt es werden Millionen von Datensätzen gelesen um 1000 auszugeben.

Die Query ist: alles aus der Tabelle Aufträge (nur Spalten, die auch tatsächlich in der Tabelle sind, nicht dass die Ameise noch JOINen muss)
Da gibt es nichts dran zu optimieren

 

[MichaelH]

Ah ja, jede Zeile im CSV besteht nur aus 1 Eintrag in der Tabelle "Aufträge" ?
Toll, das wäre ja eine wirklich optimierte WAWI du da hast.

Ich denke du hast keine Vorstellung von einer Ameise und was die können muss.
Eine Autobahn ist für dich 3spurig, geht nur gerade aus und ist immer leer, weil sie nur nach deinen Vorstellungen gebaut wurde ?

 

[sebjo82]

Ah ja, jede Zeile im CSV besteht nur aus 1 Eintrag in der Tabelle "Aufträge" ?

Korrekt, damit man Äpfel mit Äpfeln vergleichen kann.

Ich denke du hast keine Vorstellung von einer Ameise und was die können muss.

Ich glaube da sind wir beide auf einem Level
Unterschied zwischen uns ist, dass ich versuche Informationen zu bekommen, warum das so ist und EVENTUELL vielleicht sogar so sein muss, während du grundlos defensiv wirst und meine Person angreifst

Fun Fact: hatte in der Ameise noch JOINs drin, da der Auftrags-Export externe Spalten enthält. Nun gibt der Ameisen-Export nur noch Spalten aus, die auch tatsächlich in der einen Tabelle liegen. Lustigerweise ist SSMS jetzt bei 200k Zeilen (plus ein paar Sekunden für die .csv Erstellung, was die Ameise ja direkt macht) pro Sekunde, die Ameise immer noch bei 100. Nun ist die Frage, dauern die Queries der Ameise so lange oder liegt es am Erstellen der .csv? Man sollte ja annehmen, dass die Queries durch die Anpassung erheblich schneller hätten werden müssen (siehe den Boost im SSMS von 30k auf 200k pro Sekunde), man sieht aber 0 Unterschied

 

[MichaelH]

Klar, wenn man Beiträge nachträglich im Inhalt ändert so wie du das machst ... darf man sich nicht wundern.

Ich denke du hast jetzt ausreichend Info. 😘

 

[sebjo82]

Was hab ich denn geändert? Nichts, was dein Argument in irgendeiner Weise stützt. Es sieht jetzt sogar noch düsterer aus

 

[MichaelH]

Wie gesagt, versuch mal ansatzweise zu verstehen wir man eine Ameise programmieren "könnte" und die ist zudem schon mehr als 10 Jahre alt, dann können wir ggf. weiter diskutieren um etwas was sich in den nächsten Jahren sicherlich nicht ändern wird.

 

[sebjo82]

Ich frage warum die Ameise (es ist auch nicht nur die Ameise, alles in der Wawi ruckelt) so langsam ist, JTL ist der Entwickler, nicht du oder ich. Wenn ich einen DB Export selber programmieren wollte/könnte wäre ich nicht hier

 

[MichaelH]

Deine Frage war: "Diagramm bei Statistik deaktivieren!"
Dann ging es plötzlich um die Ameise.
Und egal was man dir versucht verständlich zu machen nützt nix.

 

[sebjo82]

Du hast nichts verständlich gemacht. Du weißt ebenso wenig warum es diese Leistungs-Probleme gibt wie ich.

und die ist zudem schon mehr als 10 Jahre alt

Das SSMS ist 2005 rausgekommen. Was ist dein Punkt?

 

[MichaelH]

BitCoin gibt es seit 2009, kann ich in deinem Shop damit bezahlen ?

Sinnlose Diskussion mit dir ... ich bin raus.