Neu Wawi seit Version 1.4... deutlich langsamer

[macler]

Hallo zusammen,
vor dem Update auf die 1.4er Version habe ich einen neuen PC mit SQL Server 2017 eingerichtet. Ich dachte die ohnehin schon nicht schnelle Wawi wird dadurch etwas schneller. Leider nicht.
Auf den Clients hat sich nichts geändert. Seit die 1.4er installiert ist, läuft alles deutlich langsamer auf zwei Clients. Zum testen habe ich einen weitern PC mit Win7 Standardkonfiguration eingerichtet, sonst läuft da gar nichts darauf und siehe da, das Artikelauswählen oder das Kundenanlegen geht deutlich schneller. Jetzt stellt sich die Frage, mit was verträgt sich die 1.4er auf den Clients nicht? Dort laufen die Officeanwendungen wie Outlook, Excel Word, dann noch Avira, mehr nicht.
Vielleicht hat jemand eine Idee?

 

[forumjtlolshopag]

Wie sieht die CPU Auslastung der Datenbank aus? Wir finden selbst unter 1.3 ist die WAWI in einigen Situationen recht lahmarschig, aber oft hängt es mit den Daten zusammen, die abgefragt werden müssen. Wenn man in den Tabellen z.B. die zeitliche Einschränkung rausnimmt und es immer alle Daten holen / listen muss, dauert es dann auch länger und wird mit der Zeit immer langsamer.

Was wir so machen:

• Generell immer die zeitlichen Einschränkungen aktiv lassen (z.B. letzten 90 Tage)
• Die Elementanzeige in den Globaleneinstellungen reduzieren. Glaub standardmäßig sind es 1000, das reicht meistens
• Wenn man hauptsächlich mit Artikelnummer sucht, dann die Suche auch nur auf Artikelnummer einschränken. Das macht die Suche flotter
• Falls bestimmte Seiten einfach zu lang dauern, über den SQL Management Studio prüfen, welche Abfragen da abgefeurt werden (So haben wir damals einen Bug unter Marktplätze gefunden, wo keine Indices für die Amazonlistings gesetzt waren(müsste mit 1.4 geklärt sein) und deshalb dort der Server immer sehr schwitzen musste)

Weitere Tipps wären hilreich, wenn noch jemand was hat.

 

[Enrico W.]

Na ja - wenn Du schon einen weiteren Client eingerichtet hast und dort und auf dem Server läuft alles halbwegs vernünftig, dann ist der Flaschenhals bei den betroffenen Clients zu suchen.
Bitte am besten mal alles abschalten wie Firewall, Virenscanner, Hardwarefirewall etc. und dann testen. Wenn es jetzt vernünftig läuft, dann ist das Problem da zu suchen. Dann systematisch alles eins nach dem anderen aktivieren und wieder testen, bis die Ursache gefunden wurde.

 

[elcheffe]

läuft auf den zwei Clients Win7?

 

[macler]

läuft auf den zwei Clients Win7?

Ja, auf den Clients Win 7 und auf dem Server Win10.
Mir kommt es vor, dass die Abragen zum Server deutlich länger dauern als vorher.

 

[elcheffe]

Ich glaub das Problem ist ein alter Hut.

Setz mal zum Testen einen Win10 Client auf. Dann sollte die Wawi deutlich schneller laufen, du wirst Augen machen.

Das Problem ist nicht Win7 selbst. Ich kann mich aber nicht mehr genau erinnern (vlt. findest du auch einen alten Post von mir indem darauf genauer eingegangen wird), glaube der Knackpunkt war irgendein veraltetes Framework (wahrscheinlich .NET).

 

[Enrico W.]

Welche Tests hast Du denn mittlerweile bereits durchgeführt mit welchem Ergebnis?

 

[macler]

Die globalen Einstellungen in der Wawi habe ich geändert, aber keine Veränderung.
Wir grenzen auch die Suche immer ein wenn möglich, also letzte 30 Tage in den Aufträgen etc.
Auffällig langsam sind eben Neukundenanlage, Artikel öffnen über die Baumstruktur, offene Posten.

Das Update auf WIN10 bricht leider immer wieder ab, sodass ich noch nicht mit WIN10 testen konnte.
Mit dem SQL Manager habe ich keine Erfahrungen, deshalb kann ich da nicht testen.

Kontinuierlich alles abzuschalten bringt mich nicht wirklich weiter. Was nützt es wenn ich weiß, dass Outlook oder Excel oder Avira ein Problem mit der Wawi haben, die kann nicht einfach weglassen und nur alleine mit der Wawi arbeiten.
Bei dem Testrechner und bei den Live PCs ist jeweils .Net 4.7.2 installiert. Deshalb ist das mit dem alten Framework noch nicht die wirkliche Ursache, denke ich.
Auf der anderen Seite ist das die einzige Software, die sich seit dem Update der Wawi an beiden PCs geändert hat. Vielleicht macht die .Net ein Problem mit der Wawi.
Aber das sollte JTL doch beantworten können.

 

[do1emu]

Der JTL-Support hat zu mir sogar mal gesagt (und er weiß auch nicht warum) wenn man die Datensätze auf 10.000 stellt dann geht es flotter. Konnte das aber nicht bestätigen. Die Suche in der 1.4 findet auch zur Zeit doppelt statt. Der Fehler soll ab der 1.4.33 behoben sein, die evtl heute noch rauskommt. Die Spaltensortierung aufheben hilft auf jeden Fall, um Suchergebnisse flotter darzustellen, aber auf die kann ich nicht verzichten...

Die 1.4.32. hat einen weiteren Schwachpunkt. Artikel + Eigene Felder + Warengruppen ergeben ein Problem. Je mehr Kombinationen es gibt, desto länger dauert das Aufrufen - soll ebenfalls mit 1.4.33 behoben sein. Ich finde es persönlich immer lustig, dass JTL ein Update macht, danach läuft es nicht mehr so und man versucht die Ursachen woanders zu finden, weil es immer User im Forum gibt, die sagen, dass alles reibungslos läuft. Ich denke den Umfang indem JTL genutzt wird, ist entscheidend! Man muss sich auch fragen wie definiert man "flott". Wenn ich 10.000 Aufträge aus den letzten 30 Tagen habe und ich suche nach einem ist dann 1 sek Wartezeit ok? Oder doch nur 0,3 Sek? Ich für meinen Teil behaupte, dass die aktuelle Wawi den AUftrag in 0,3 Sek findet und anzeigt, dann allerdings nochmal sucht und warum auch immer 2-3 Sekunden braucht um das Ergebnis erneut anzuzeigen.

 

[MichaelH]

Du sprichst vom Bug der korrigiert wurde/wird.
Die Datensätze auf 10.000 einstellen hat den Vorteil, dass die Anzahl der Sätze von vornherein auf 10.000 limitiert wird und das ist tatsächlich sinnvoll im Alltag.

Also neue Version abwarten, das wird schon.

 

[macler]

Ich habe heute die neuste Version 1.4.33 installiert und merke bisher deutliche Besserung in den angesprochenen Punkten. Also liegt es doch an der Wawi und nicht an der Umgebung.

 

[deliman]

Hallo,

bei uns ist der Artikelaufruf und das -Speichern mit der 1.4.33 deutlich langsamer als in der 1.4.29.

 

[macler]

Ich muss meinen letzten Post zurücknehmen. Die 1.4.33 ist wieder genauso langsam wie die Vorversion.

Folgende "Schnelligkeitstests" habe ich jetzt mal gemacht. Immer ohne dass noch jemand anderer an der Wawi angemeldet ist.
Artikel öffnen per Doppelklick: PC1 WIN7 = 8 Sec. PC2 WIN7 = 8 Sec. PC3 WIN10 = 8 Sec. Test mit 6 Artikeln, teilweise mit Varkombis und ohne.
Umschalten per Mausclick von einer Unterkategorie zur Anderen: PC1 WIN7 = 7 Sec. PC2 WIN7 = 7 Sec. PC3 WIN10 = 7 Sec. Test mit 5 Unterkategorieen.
Diese Test habe ich über den Morgen verteilt 4 Mal wiederholt, immer mit den selben Ergebnissen. Auf allen PCs war während der Tests die Firewall abgeschaltet. Ebenso kein Worker oder Hintergrundprozesse von mir gestartet.
Teilweise kam es vor, dass z.B. das Artikelfenster nicht mit allen Inhalten angezeigt wurde, ein switchen zwischen der Wawi und Outlook z.B. hat dann den restlichen Inhalt angezeigt, scheinbar ein Refreshproblem.
Somit komme ich zum vorläufigen Ergebnis, dass die Langsamkeit nichts mit der Windowsversion oder den Programmen im Hintergrund zu tun hat. Auf dem WIN10 Rechner läuft gar nichts ausßer die Wawi, nicht mal Avira.

 

[deliman]

@macler

Ohne die genaue Zeit gemessen zu haben, kann ich die gemachten Angaben bestätigen Artikel Öffnen und Schließen je gefühlt 10 Sec, Kategoriewechsel - dauert deutlich länger als vorher.

Beim Speichern von Änderungen im Artikel geht erst das Bearbeitungsfenster zu aber der Speichervorgang ist noch nicht abgeschlossen. Wenn man dann bereits den nächsten Artikel anklickt, steigt die Wawi aus bzw. zeigt an Wawi(Anwendung) reagiert nicht. Echt nervig.

 

[hula1499]

7-8 Sek? Wow, das ist echt vollkommener Mist (vorallem wenn die WaWi lokal ist).

Was da an Mitarbeiterzeit (und Kosten) draufgeht, hochgerechnet....

Hast schon mal jemanden deinen SQL anschauen lassen? Die Einstellungen auf der JTL Guide bist durchgegangen?

7-8 Sek....ich krieg schon alle Zustände, wenn ich die WaWi von extern aufrufen und 4-5 Sek. auf ne Artikelöffnung warten muss.

 

[gnarx]

1. Moin du solltest erstmal hier posten deine JTL-Server Konfiguration, also wie viele Festplatten usw.. Wenn mehrere Festplatten wurden bei der Installation die Daten, Temps und Logs auf die verschiedenen Festpaltten gelegt?
2. Hast du die Datenbank optimiert? Siehe hier: https://www.jtl-software.de/blog/loesungen-von-jtl/optimale-einrichtung-der-sql-datenbank das solltest du unbedingt machen.
3. Hast du die Bilder in JTL unter Lager -> Bildgrößen runter rechnen lassen?

 

[gnarx]

Bei uns Artikel öffnen bei 130.000 Artikel auf dem Server 1-2 sek..

 

[deliman]

OK. Heute noch mal Datenbank bereinigt, repariert und optimiert via Wawi Datenbanktool und sieh da, der Artikelaufruf ist wieder gewohnt schnell 1-2 Sec.

 

[Thomas Lisson]

Danke für Rückmeldung.
@macler Kannst du mal das gleiche machen wie deliman und dann schauen?

 

[maydo]

in dem Zusammenhang will ich noch folgendes hinzufügen.

Das Artikelöffnen ist in der Tat sehr langsam, im Vergleich zu allem anderen was sehr performant ist.

Was bei uns extrem stört ist die Artikelsuche, wenn Artikelnummern aus reinen Buchstaben bestehen.

Eine Suche nach EAN dauert gefühlt weniger als eine sekunde (sehr schnell), aber eine Artikelnummernsuche die aus reinen Buchstaben besteht dauert fast 10 sekunden.
Eine Suche nach Zahlen egal ob Artikelnummern EAN HAN etc. dauert nur einen Bruchteil davon.

Ich denke da ist irgendwas faul wenn Buchstaben und evtl. auch Zeichen enthalten sind.
abcdefgh_abc < betrifft dieses format

Groß und Kleinbuchstaben gemischt, in dem Format sind einige unserer Artikel.

Update:
ich habe eben noch einiges gestestet, es scheint an dem Unterstrich zu liegen "_"
Beim Bindestrich "-" tritt das Verhalten nicht auf

Wenn Unterstrich enthalten dann dauert die Suche ca, 10x so lange.