[gelöst] Artikelkarte beim Öffnen sehr langsam

Hallo zusammen,

bei uns öffnet sich die Artikelkarte extrem langsam (15 Sekunden).
Gefühlt ist das Problem das erste Mal aufgetreten, nachdem wir das CU-Update auf die Version 9.00.51811 durchgeführt haben.
Das Navision läuft bei uns in einer Citrix-Umgebung.

Diese große Verzögerung tritt bei allen Anwendern und auch bei verschiedenen Navision-Diensten auf. Wenn die Karte dann geöffnet ist, dann ist alle gut. Das Blättern durch di einzelnen Datensätze geht sehr schnell und die Verzögerung tritt nicht mehr auf. Wenn ich die Karte schließe und wieder öffne, dann tritt die 15 Sekunden Verzögerung wieder auf.

Wenn ich das Ganze mit der Artikelkarte im Browser mit dem Web Client durchführe, tritt diese Verzögerung auch nicht auf.
Wenn ich vorm Schließen der Artikelkarte im Windows-Client alle Inforegister schließe, also minimiere, dann öffnet sich die Artikelkarte auch immer sehr schnell.
Ich habe auch testweise Mal alle Aufrufe im OnOpen-Trigger deaktiviert, was aber nichts an dem Problem geändert hat.

Hat einer von euch eine Idee, wie wir es hinbekommen, dass sich die Artikelkarte wieder schnell öffnet?

Danke.

Gruß
Alexander

Zuletzt geändert von zannaleer am 10. November 2020 12:12, insgesamt 1-mal geändert.

Hallo,

das hört sich nach suboptimalen FlowField (Schlüsseln) und unpassenden Filtern an.
Das Problem ist eigentlich bekannt, tritt aber bei jedem Anwender anders auf.

Am besten schaust du dir die langsamen Abfragen mal im SQL-Server- Monitor an, und optimierst dann mit passenden Filtern und schlüsseln.

Gruß Fiddi

Hallo Fiddi,

würde das dann nicht auch dann auftreten, wenn ich durch die Datensätze blättere oder die Artikelkarte im Web Client aufrufe?
Langsame SQL-Abfragen werden ja auch im Event Log protokolliert und da steht in diesen Fällen nichts.

Gruß
Alexander

Hallo,

das sollte natürlich auch auftreten, wenn du durch die Datensätze blätterst, muss aber nicht.
Beispiel:
wg. eines suboptimalen Schlüssels sind die Abfragen langsam. Außerdem hast du einen Artikel am Anfang der Liste, der etwas mehr Posten hat, und dementsprechend länger braucht, als die normalen Artikel mit weniger Posten.

und im Log muss nichts stehen wenn es sehr viele Abfragen sind.
Des weiteren kann natürlich auch suboptimal Programmierung mit vielen CurrPage.Update's oder auch die Info-Boxen das Leben erschweren.

Gruß Fiddi

Hallo Fiddi,

aber warum ist es dann im Web Client schnell?
Wenn ich zum Beispiel von Artikel A zu Artikel B blättere, dann ist es schnell.
Schließe ich die Artikelkarte und öffne dann Artikel B direkt aus der Übersicht, dann ist es wider langsam.

Info-Boxen habe ich mal alle ausgeblendet, das hat leider auch gar nichts gebracht.

Danke.

Gruß
Alexander

Hallo,

schau die den SQL-Monitor an, der sollte einiges erklären.

Gruß Fiddi

Das klingt für mich nach FlowFields in den FactBoxes, welche Daten gefiltert summieren/zählen, ohne dass es einen dazu passenden Index auf dem SQL-Server gibt.

Das Thema Performance war, ist, und wird wohl auch immer ein Thema bleiben.
Wir haben aus diesem Grund in regelmäßigen Abständen kurze "Performance-Workshops" mit Jörg Stryk.
Diese Workshops dauern jeweils nur 3-4 Stunden und laufen über TeamViewer und Telefonkonferenz.

In den allermeisten Fällen waren es bei uns wirklich Index-Probleme.
Die meisten davon konnte man durch erstellen passender Keys in NAV lösen, aber in einigen Fällen bietet NAV gar nicht die Möglichkeit einer passenden Lösung.
Dann legt Jörg einfach auf dem SQL-Server direkt einen optimierten Index an.

Die Statistiken zeigen, dass diese neuen Indizes schon kurz nach der Erstellung sehr häufig vom SQL-Server genutzt werden und einen enormen Performance-Schub bringen, den man nicht nur messen, sondern auch als Anwender spüren kann.

Von daher kann ich nur empfehlen, dass ihr einmal einen Termin mit Jörg Stryk vereinbart.

Hallo,

wann hast du denn auf eurem SQL- Server das letzte mal sp_updatestats oder den Job Statistikupdate laufen lassen?

Gruß Fiddi

SQL und Flowfields etc hin oder her
könnte es nicht sein, dass eine Programmierung im OnOpenPage-Trigger enthalten ist?
ggf. prüft diese ja auch auf die Clientart und wird z.B. im WebClient nicht ausgeführt?

Ja, im OnOpen-Trigger sind Programmierungen enthalten.
Aber selbst wenn ich diese auskommentiere hat das keine Auswirkung.
Die Page öffnet sich trotzdem langsam.

Interessant ist auch noch folgenden.
Wenn ich die Page bei allen drei Auswahlmöglichkeiten auf die Standard-Einstellung zurücksetze, öffnet sich die Page einmal normal schnell und danach auch wieder langsam.

Hallo,

nochmal die Frage: Wann hast du das letzte mal die Statistiken der SQL-Datenbank aktualisiert?

Gruß Fiddi

Hallo,

ich habe gerade unsere SQL-Statistiken ausgelesen und kann an diesen nichts feststellen, was zu meinem Problem führen könnte.

Gruß
Alexander

Hallo,

was hast du denn ausgelesen? Hast du bei jeder Tabelle und jedem Index die Statistikwerte geprüft?

Der Aufruf von sp_updatestats im SQL-Server sorgt dafür, dass der SQL-Server besser in der Lage ist geeignete Schlüssel für die Suche nach Datensätzen zu verwenden.

Diesen Aufruf kann man als Wartungsjob mit dem SQL-Server Agent ausführen lassen. Der läuft dann einmal die Woche und aktualisiert die Werte. Oder man macht das eben manuell über die Funktion

Insbesondere bei Datenbanken, die von 0 an gewachsen sind, kann der regelmäßige Aufruf dieser Funktion dazu führen, dass der SQL-Server Daten schneller/besser findet, und sich damit die Antwortzeiten verbessern.

Was aber nicht heißt, das man durch geeignete Programmierung in NAV nicht erheblich mehr raus holen kann.

Gruß Fiddi

Hallo,

ich habe das Stryk-Tool verwendet.
Wie gesagt, haben wir damit nichts gefunden.
Und um meine ursprüngliche Frage zurückzukommen. Läge es am SQL-Server, wäre es dann nicht bei jedem Blättern auch langsam und im Web Client?
Unser Problem tritt nur im Windows-Client auf und auch nur beim Öffnen der Page. Ist die Page geöffnet, dann kann ich rasend schnell durch die Datensätze blättern.

Gruß
Alexander

nimm doch mal die ItemPage von vor dem CU-Update und teste mit der (außer du hast keine Anpassungen oder sonstige Module dran)
PS: habt ihr Extensions im System?

Hallo,

versuch doch mal mit der SQL-Ablaufverfolgung den Übeltäter zu lokalisieren.

in den neueren Versionen wird da auch schon mal die SalesForeCast- Extension von Microsoft aktiviert, die dort für Performance- Probleme verantwortlich ist.

Gruß Fiddi

Hallo,

um die SQL-Ablaufverfolgung zu starten, muss ich doch nur den SQL Server Profiler starten und dann auf 'Neue Ablaufverfolgung' klicken, oder?
Das habe ich gerade mal gemacht und dann die Artikelkarte geöffnet.
Wonach sollte ich jetzt Ausschau halten?

Unter meinem Benutzer habe ich nichts gefunden.
Oder müsst dort etwas sein bei dem Benutzer, mit dem der NAV-Dienst läuft?

Danke.

Gruß
Alexander

Hallo,

Ja, so in etwa wird das gemacht.

Leider kannst du nicht anhand deines Benutzernamens etwas finden.

Diesen Test macht du am besten, wenn du alleine im System bist (oder auf einem Testsystem). Dann bist du alleine für den aufgezeichneten Traffic verantwortlich.

In der Ablaufverfolgung suchst du dann nach Einträgen, die eine Menge CPU-Zeit verbraten oder viele Reads verursachen.
Danach musst du raus finden welcher SQL-Befehl dort ausgeführt wird (ist manchmal nicht ganz einfach, weil dort Stored Procedures ausgeführt werden, deren Definition du weiter vorne im Log findest, wenn du deine Session komplett ab dem Start des Clients aufgezeichnet hast.)
Zu guter Letzt, musst du diesen SQL-Befehl noch NAV- Code/Feldern/Schlüsseln zuordnen und ggf. korrigieren.

Solltest du keine höheren CPU- Zeiten oder besonders viele Reads (auch viele einzelne hintereinander), solltest du nach einer zeitlichen Lücke im Protokoll suchen.
Das könnte der Zeitpunkt sein, an dem ein Webservice aufgerufen wird, um z.B. den Sales Forecast zu füttern.

Gruß Fiddi

Hi,

wir hatten das Problem mit dem Feld "Einstandspreis ist auf Sachkonten gebucht" auf der Karte. Als es entfernt wurde (nicht nur visible=false) war alles wieder schnell.

Hallo zusammen,

wir haben am Wochenende ein CU-Update durchgeführt.
Jetzt öffnet sich die Seite deutlich schneller.

Danke für alle Hinweise.

Gruß
Alexander

Das klingt für mich nach FlowFields in den FactBoxes, welche Daten gefiltert summieren/zählen, ohne dass es einen dazu passenden Index auf dem SQL-Server gibt.

Das Thema Performance war, ist, und wird wohl auch immer ein Thema bleiben.
Wir haben aus diesem Grund in regelmäßigen Abständen kurze "Performance-Workshops" mit Jörg Stryk.
Diese Workshops dauern jeweils nur 3-4 Stunden und laufen über TeamViewer und Telefonkonferenz.

In den allermeisten Fällen waren es bei uns wirklich Index-Probleme.
Die meisten davon konnte man durch erstellen passender Keys in NAV lösen, aber in einigen Fällen bietet NAV gar nicht die Möglichkeit einer passenden Lösung.
Dann legt Jörg einfach auf dem SQL-Server direkt einen optimierten Index an.

Die Statistiken zeigen, dass diese neuen Indizes schon kurz nach der Erstellung sehr häufig vom SQL-Server genutzt werden und einen enormen Performance-Schub bringen, den man nicht nur messen, sondern auch als Anwender spüren kann.

Von daher kann ich nur empfehlen, dass ihr einmal einen Termin mit Jörg Stryk vereinbart.

Hallo Timo,

ja, gute Idee. Wir habe das Stryk-Tool zwar schon laufen, aber vielleicht wäre tatsächlich mal wieder ein gemeinsamer Termin mit Jörg Stryk sinnvoll.

Danke für den Denkanstoß. Ich werde das mal intern bei uns zur Sprache bringen.

Gruß
Alexander