Moin Moin erstmal,
ich bin neu hier und beschäftige mich seit ca. 2 - 3 Wochen mit JTL-Wawi (Version 1.5.44.0).
Im Rahmen einer Testinstallation ist mir aufgefallen das die Wawi an einigen stellen etwas zähflüssig läuft bzw. kurzfristig hackelig ist.
Dies habe ich zunächst auf den Umstand abgeschoben das in der Standardinstallation der SQL-Server Express verwendet wird. In meiner Testinstallation Windows Server 2012 R2 mit SQL Server Express 2017 in einer Hyper-V VM.
Da ich eigentlich mit Oracle- und MySQL-Datenbanken zu tun habe, dachte ich zunächst einmal an die Performance von MS SQL-Server im allgemeinen und die der Express Edition (eingeschränkte Resourcennutzung) im speziellen.
Im Forum / bei Youtube fand ich dann den Hinweis auf das cfgtool zur Verbesserung der Datenbankperformance, dieses ist in der aktuellen Version nicht verfügbar und durch JTLDiag ersetzt worden, zunächst kein Problem.
Leider funktioniert die Einbindung der "SQL-Server-Konfiguration" nicht (als einziger Punkt, die anderen arbeiten ohne Probleme (siehe Symbole am Rand):
Die Einbindung von "SQL-Server-Konfiguration" schlägt bei jeder Variante fehl, unabhängig davon ob die Sitzung aufgezeichnet wird, welches Authentifiztierungsverfahren genutzt und ob die Datenbank über Standard oder direkte Angabe ausgewählt wird, JTLDiag bringt immer die Fehlermeldung.
Worum es aber eigentlich geht:
Da der SQL-Mitschnitt funktioniert, fand ich die Ursache für das teilweise hacklige Verhalten des Clients:
Dieses Statement korreliert ziemlich offensichtlich mit dem am Client beobachtetem Verhalten.
Es werden lediglich sämtliche Tabellen des aktuellen Datenbankschemas mit dem Datum des letzten Updates ausgelesen (778 Rows):
Vermutlich erklärt sich das dadurch das der SQL-Optimizer hier nicht greift, durch eine kleine Änderung am Statement läßt sich die Performance deutlich verbessern:
Statt "SELECT * FROM ..." einfach "SELECT TableName, LastUpdate FROM...":
Die obere der beiden Abfragen in der zur Zeit implementierten Form, die Untere mit der geringfügigen Änderung aber gleichem Ergebnis (zumindest wie ich es lt- Ausgabe SQL-Konsole beurteilen kann.
Diese Abfrage wird z.B. bei Aufruf eines bestehenen Artikels / Kunden genutzt, bei Lieferanten ist dieses nicht enthalten. Über Zweck und Notwendigkeit dieser Abfrage kann ich nur Vermutungen anstellen.
Optimalerweise wird diese entfernt, sollte sie aber notwendig sein wäre ich für eine Implementierung der optimierten Version sehr dankbar.
Ansonsten bin ich mit dem was ich bisher gesehen habe sehr zufrieden, für ein kostenloses Produkt sehr ausgereift (für ein kostenpflichtiges wäre es das auch, aber es sei noch einmal gesondert erwähnt).
Wenn ich nächste Woche die Installation beim Kunden vornehme wird dieser sicher auch über dieses Verhalten stolpern, insbesondere da der Grund für die Umstellung auf JTL-Wawi unter anderem die schlechte Performance des bisher verwendeten Produktes ist.
Hinweis für Serverbetreiber:
Falls der verwendete Server (in meinem Fall HP-Proliant) eine BIOS Option zum Thema Performance anbietet, dann immer Static High Performance oder je nach Modell entsprechendes auswählen, das gibt der Datenbankperformance insgesamt einen deutlichen Schub.
ich bin neu hier und beschäftige mich seit ca. 2 - 3 Wochen mit JTL-Wawi (Version 1.5.44.0).
Im Rahmen einer Testinstallation ist mir aufgefallen das die Wawi an einigen stellen etwas zähflüssig läuft bzw. kurzfristig hackelig ist.
Dies habe ich zunächst auf den Umstand abgeschoben das in der Standardinstallation der SQL-Server Express verwendet wird. In meiner Testinstallation Windows Server 2012 R2 mit SQL Server Express 2017 in einer Hyper-V VM.
Da ich eigentlich mit Oracle- und MySQL-Datenbanken zu tun habe, dachte ich zunächst einmal an die Performance von MS SQL-Server im allgemeinen und die der Express Edition (eingeschränkte Resourcennutzung) im speziellen.
Im Forum / bei Youtube fand ich dann den Hinweis auf das cfgtool zur Verbesserung der Datenbankperformance, dieses ist in der aktuellen Version nicht verfügbar und durch JTLDiag ersetzt worden, zunächst kein Problem.
Leider funktioniert die Einbindung der "SQL-Server-Konfiguration" nicht (als einziger Punkt, die anderen arbeiten ohne Probleme (siehe Symbole am Rand):
Die Einbindung von "SQL-Server-Konfiguration" schlägt bei jeder Variante fehl, unabhängig davon ob die Sitzung aufgezeichnet wird, welches Authentifiztierungsverfahren genutzt und ob die Datenbank über Standard oder direkte Angabe ausgewählt wird, JTLDiag bringt immer die Fehlermeldung.
Worum es aber eigentlich geht:
Da der SQL-Mitschnitt funktioniert, fand ich die Ursache für das teilweise hacklige Verhalten des Clients:
Dieses Statement korreliert ziemlich offensichtlich mit dem am Client beobachtetem Verhalten.
Es werden lediglich sämtliche Tabellen des aktuellen Datenbankschemas mit dem Datum des letzten Updates ausgelesen (778 Rows):
Vermutlich erklärt sich das dadurch das der SQL-Optimizer hier nicht greift, durch eine kleine Änderung am Statement läßt sich die Performance deutlich verbessern:
Statt "SELECT * FROM ..." einfach "SELECT TableName, LastUpdate FROM...":
Die obere der beiden Abfragen in der zur Zeit implementierten Form, die Untere mit der geringfügigen Änderung aber gleichem Ergebnis (zumindest wie ich es lt- Ausgabe SQL-Konsole beurteilen kann.
Diese Abfrage wird z.B. bei Aufruf eines bestehenen Artikels / Kunden genutzt, bei Lieferanten ist dieses nicht enthalten. Über Zweck und Notwendigkeit dieser Abfrage kann ich nur Vermutungen anstellen.
Optimalerweise wird diese entfernt, sollte sie aber notwendig sein wäre ich für eine Implementierung der optimierten Version sehr dankbar.
Ansonsten bin ich mit dem was ich bisher gesehen habe sehr zufrieden, für ein kostenloses Produkt sehr ausgereift (für ein kostenpflichtiges wäre es das auch, aber es sei noch einmal gesondert erwähnt).
Wenn ich nächste Woche die Installation beim Kunden vornehme wird dieser sicher auch über dieses Verhalten stolpern, insbesondere da der Grund für die Umstellung auf JTL-Wawi unter anderem die schlechte Performance des bisher verwendeten Produktes ist.
Hinweis für Serverbetreiber:
Falls der verwendete Server (in meinem Fall HP-Proliant) eine BIOS Option zum Thema Performance anbietet, dann immer Static High Performance oder je nach Modell entsprechendes auswählen, das gibt der Datenbankperformance insgesamt einen deutlichen Schub.
