Sage Performance sehr schlecht

TechnikOnkel

Neues Mitglied
Hallo zusammen,

ich habe hier einen Kunden, der sich über die Performance von Sage100 beschwert.
Nach der Angabe des 4. Lieferscheins wird die Eingabe / Maske immer langsamer.

Der Server hat genügend RAM und CPU.
Ist die Sage einfach so schlecht? Es kommt ständig der berühmte "Wird geladen" Hinweis.

Vielen Dank
 
schreibt der Kunde die 4 Belege hintereinander oder über den Tag verteilt und verlässt zwischenzeitlich die Terminalserversitzung?
 
Er schreibt die Belege direkt hintereinander.
Wenn er das Programm schließt wird auch die Sitzung beendet.

Ist aber nicht nur beim Belege erfassen. Auch generell langsam und es kommt häufig "Wird geladen". Das kommt zwar auch aber durch diese Meldung wirkt es etwas träge.
 
Ja, das stimmt schon! Die Masken laden nicht sonderlich schnell obwohl der Server viel Power hat.
Wir haben einige TS auf 2019er Basis im Einsatz und bis jetzt keine Schwierigkeiten in Bezug auf die Performance der Masken feststellen können. Habt ihr einen Virtualisierer auf dem der TS läuft oder einen "Bare-Metal"?

Ist die Access Speichererweiterung (einzuschalten im Sage Admin) aktiv?
 
habt ihr die Performance-Dokumente/Checklisten mal durchgearbeitet. Meist sind es nachher Dinge wie Energiespareinstellung im Bios o.ä.
 
Hallo TechnikOnkel, hallo Forum,

wir arbeiten produktiv auf der Sage 100 9.0.4.11.

Das größte Manko - die meisten Klagen resultieren aus der schlechten Performance der Sage.

Vor allem Stammdaten-Artikel (Umschalten der Darstellung - oder auch Massenbearbeitung von Artikeln - bis die geändert-Meldung kommt und bestätigt ist) und die Belegbearbeitung EK wie VK- Belege (wer hier schnellen Text schreiben will kann den Buchstaben hinterherschauen) ist eine Qual.
Ich spreche nicht vom Start der Software - oder vom Öffnen von Masken - das ist natürlich auch nicht wirklich schnell.
Mich ärgert die Performance innerhalb der Masken - beim Ausfüllen von Feldern etc. beim Schreiben von Texten und beim Speichern (grüner Balken) selbst.

Es macht einfach keinen Spaß - das System hält mit den Benutzern nicht Schritt.

Ich habe die Performance-Dokumente schon durch - selbst mit Hyperthreading (ein/aus) experimentiert diverse Konstellationen von SSD's im Server mit RAID und ohne RAID, dedizierte NvME für die VM des App-Servers ...
Host und VM's laufen maximal mit 1/3 Prozessorauslastung - aber auch bei nur 5% Prozessorauslastung mit nur einem User (am Abend) ist die Sage 100 träge.
Die 7.1 war selbst auf älterer Hardware innerhalb der Masken bei der Bearbeitung von Stammdaten oder Belegen bei weitem nicht so träge.

Mein Prozessor ist ein AMD EPYC mit einem Basistakt von 3 GHz, ausreichend RAM, 10Gbit Netzwerkanbindung an den Switch...

Was ich mit dem Tool VMMAP festgestellt hatte ist, dass sowohl die VM mit dem Sage-Applikationsserver, als auch die VM mit dem "Terminalserver" zwar die Access- Speicherwerweiterung im Sage- Administrator "aktiviert" haben - aber laut Tool trotzdem nicht tun.
1 x ist es die Access 2016 Runtime von der Sage- DVD, 1 x Office 2019 prof. Plus mit Access 2019 Vollversion.
Wir haben aber gar keine AddIns am Laufen - sonder fast nur 100% AppDesigner Zusatzlösungen.

@breithecker: macht Ihr noch Performance- Optimierungen / Analysen von Sage 100 Systemen ?

Alle Server laufen die meiste Zeit quasi im Leerlauf - die Leistungsindikatoren vom Sage- Applikationsserver sind weit weg von einer Grenze.

Ich habe den Eindruck, dass die Sage 100 immer mit angezogener Handbremse läuft.
Das gilt sowohl für Sage in Sitzungen auf dem Terminalserver - wie auch in einer Sitzung auf dem Applikationsserver.
 
ja, machen wir noch.

ich kann das mit der Performance nur in Teilen bestätigen. Wir haben auch sehr viele Kundeninstallationen die sehr performant laufen.

Viele Grüße
 
Hallo in die Runde,

Sind Application-Server und Terminal-Server getrennt aufgesetzt ?
Wenn ja, bitte einmal prüfen wie die Performance direkt auf dem Application-Server ist und Rückmeldung geben.

Beste Grüße Rouven
 
App Server und Terminalserver sind zwei getrennte VM‘s auf dem gleichen Host
Auch auf dem App- Server ist die Performance nicht wirklich besser.

Sage 100 Rewe ist von der Performance schneller als die Wawi.

Ich kenne nur zwei Produktiv- Systeme von Partnern, die etwas schneller sind als unser System. Dort sind jeweils Intel Xeon Gold- Prozessoren mit 3,2 GHz Basistakt (Turbo 3,6 GHz) im Einsatz. ImVergleich haben wir nur eine AMD Epyc mit 3 GHz und 3,2 Turbo
Aber auch diese neuenIntel- Systeme sind eigentlich viel zu träge… dümpeln oftmals im Leerlauf vor sich hin

Ich warte auf die göttliche Eingebung mit einem entscheidenden Hinweis wo der Flaschenhals der Installation ist.
(Ein Hinweis von Sage würde auch schon reichen)
 
Sage 100 Rewe ist von der Performance schneller als die Wawi.
Der Punkt ist neu für mich und ist aus meiner Sicht schon ein Wiederspruch in sich, wenn ich es korrekt verstehe. Das Lade/Speicherverhalten, zum Beispiel innerhalb der Kundenstammdaten im Rechnungswesen, unterscheidet sich mit dem der Warenwirtschaft ? Wird hier das identische Layout genutzt ? - Gleiche Register Anzahl, Userfelder, Zusatzlösungen für Wawi/Rewe ?

App Server und Terminalserver sind zwei getrennte VM‘s auf dem gleichen Host
Läuft der SQL-Server auch auf einer getrennten VM auf dem gleichen Host ? Mich würden die Einstellungen des SQL-Servers/Datenbank brennend interessieren... Stichwort - Kompatibilitätsgrad und TempDBs, weil bei fast allen (siehe Kommentar unten) genannten Punkten von Ihnen Zugriffe auf die Datenbank laufen.

wer hier schnellen Text schreiben will kann den Buchstaben hinterherschauen
Innerhalb der MultiDataEdit-Elemente (Positionserfassung) oder meinen Sie Vortexte/Endtexte ? Innerhalb eines Memofeldes ebenfalls ?

Grundsätzlich denke ich aber, dass für den von Ihnen beschriebenen Fall, es ohne hin auf eine Systemanalyse hinaus läuft . Ohne Einsicht auf Diagnose und Konfiguration der Dienste wird es schwer zu beurteilen, in welche Richtung es hier geht. Dafür spielen leider im Moment noch zu viele Faktoren eine Rolle. Ich erinnere an dieser Stelle an folgende Darstellung.

1684396714009.png

Der Aufbau des neuen Clients wird vieles einfacher machen:
1684396671151.png

Ich wünsche ein schönes langes Wochenende und viel Erfolg !
 
@ R.Ziemer,

danke für die schnelle Rückmeldung.

zu Punkt 1:
a.) Rewe startet mit ca. 12 Sekunden (vollständiges Regiezentrum, jedoch ohne Dashboard) deutlich schneller wie die Wawi (bei uns ca. 26 Sekunden bis Regiezentrum, ohne Dashboard).
Das mag auch an diversen Zusätzlösungen in der Wawi liegen. Aber auch ohne Zusatzlösungen besteht eine Differenz.
b.) die Stammdatenmasken "Kunden" und "Lieferanten" öffnen sich in etwa der gleichen Geschwindigkeit
die sonstigen Rewe- Masken (etwa Buchungserfassung oder Stammdaten-Sachkonten etc.) öffnen vergleichsweise zügig - und der Wechsel von Datensatz zu Datensatz erfolgt ohne störenden Verzug)
natürlich kann man das nicht mit den Wawi- Masken "Stammdaten-Artikel" oder "Verkaufsbelege bearbeiten" vergleichen weil es um andere Datenmengen geht - aber Reaktionszeit der genannten Rewe- Masken würde ich mir für die genannten Wawi-Masken wünschen.

zu Punkt 2:
ja der SQL- Server läuft auch auf einer dedizierten VM - auf dem selben Host wie die anderen beiden VM's für Sage.
Der Host hat nur diese 3 VM's (SQL-Server, Terminalserver, App-Server) (virtueller Netzwerkadapter mit 10GBit, Anbindung an den physischen Switch mit 10 GBit Glasfaser, Verbindung zu den WIN-10 Clients mit 1 GBit, alle Clients nutzen die Sage innerhalb einer Remotdesktopumgebung bzw. Remote-App)
Alle VM's sind Windows Server 2016 Standard mit akutellen Patches; Der SQL-Server ist ein 2016-er SQL-Server Standard (13.0.6430.49)
Die Datenbank hat den Kompatibilitätsgrad 2016 (130) und hat derzeit eine Größe von ca. 18GB (DATA ca. 11 GB; LOG ca 7GB).
Mit der tempdb habe ich micht noch nicht beschäftigt (Kompatibilitätsgrad 130, 296MB )
Die Sage- Datenbanken haben einen Wartungsplan mit täglicher Sicherung und Index neu organisieren / Statsitiken aktualisieren, sowie wöchentlicher Neuerstellung der Indexe.
Die Clientprotokolle haben TCP/IP vor Named Pipes - Named Pipes teilweise "deaktiviert"
Alle Server sind im Netzwerk mit IP oder auch Namen mit <1ms erreichbar (Min, Max, Mittelwert = 0ms). DNS-Auflösung arbeitet korrekt.


zu Punkt 3:
ja, die Verzögerung kann man in Rewe und in Wawi- Masken des AppDesigners beobachten.
Im Grunde gilt das für alle Eingabefelder und Cursor/Tab- Sprüngen zwischen den Feldern- auffällig wird das aber nur bei längeren Texten.
Die alten Access-Masken haben/hatten das nicht.
Das gilt besonders für die Langtexte oder Dimensionstexte in den Artikel- Stammdaten, für die Memo-Felder bei Artikel oder auch in den Adressen/Kunden/Lieferanten. Erkennbar ist diese "Latenz" aber in allen Feldern.
Besonders störend ist es in der Belegerfassung - unabhängig davon, ob Kopftext, Fußtext, eine Textposition (formatierter Text/unformatierter Text) oder auch dort der Dimensionstext bzw. Langtext.

Wenn Sie wirklich schnell schreiben konnen (10 Finger-System), dann können Sie wirklich erkennen, dass die Buchstaben mit einer gewissen Latenz hinterher- hinken. Diese Latenz ist nicht immer gleich - sie variiert.
Testen kann man das (wenn man nicht so schnell schreiben kann) indem man einen langen Text mit "backspace" löscht. Das geht nicht gleichmäßig - sondern auch hier mit Variierender Latenz. In der Regel trifft man die gewünschte Stelle im Text nicht - man löscht u.U. 1-3 Zeichen zu viel (wegen der Latenz).

Es gibt bei uns Tage, an denen es weniger auffällig ist - und Tage bei dem die User sagen "heute ist das System wieder langsam".

Dabei ist die "Latenz" innerhalb der Sage völlig unabhängig von der Remotdesktopumgebung und auch von den sonstigen Programmen auf dem Terminalserver. Diese "Latenzen" haben wir in Word / Excel weder auf dem Terminalserver, noch im Editor / Wordpad etc. auf dem App-Server.

zu Ihren Schaubildern:

wie genau sind denn die Datenflüsse nun, wenn ich Felder / Memofelder / Textfelder in einer AppDesigner bearbeite.
Wer kommuniziert denn während der Texteingabe mit wem ?
Ich rede nicht von einem "Speichervorgang" - sondern "nur" von der Texteingabe.
Ist da der SQL-Server überhaupt involviert?
Ist das der AppServer schon involviert?
Was läuft Client-seitig - und was Server-seitig ?

Anmerkung:
Das System ist nicht so langsam, dass man nicht mehr damit arbeiten könnte - aber eben störend träge.
Ich habe den Eindruck, dass speziell die Latenz von Sage 9.0.1 bis 9.0.4 "schlechter" geworden ist.
Funktional sind unsere Anweder im Grunde sehr zufrieden - die 9.0.4.11 läuft stabil.
Der Wunsch aller Anwender ist jedoch: "kann man die Sage nicht etwas schneller / flüssiger machen"
Das gleiche höre ich von allen unseren Partnern mit der Sage 9.0.4.

Ich wüsste nicht, was für einen Server / Prozessor / Plattensystem / Hypervisor etc. ich optimalerweise neu anschaffen sollte, damit die Sage wirklich "schnell" läuft.

Ich wollte mal einen Versuch starten die Sage auf einem Monster- Gaming- PC (hochgetaktete CPU) zu installieren - um zu sehen, ob für Sage tatsächlich die Single-Task Leistung ausschlaggeben ist. Aber da hat mein Sohn was dagegen.
 
Zuletzt bearbeitet:
Moin @cmayer ,

huii, na dann wollen wir mal ;-)
zu Punkt 3:
ja, die Verzögerung kann man in Rewe und in Wawi- Masken des AppDesigners beobachten.
Im Grunde gilt das für alle Eingabefelder und Cursor/Tab- Sprüngen zwischen den Feldern- auffällig wird das aber nur bei längeren Texten.
Die alten Access-Masken haben/hatten das nicht.
Das gilt besonders für die Langtexte oder Dimensionstexte in den Artikel- Stammdaten, für die Memo-Felder bei Artikel oder auch in den Adressen/Kunden/Lieferanten. Erkennbar ist diese "Latenz" aber in allen Feldern.
Besonders störend ist es in der Belegerfassung - unabhängig davon, ob Kopftext, Fußtext, eine Textposition (formatierter Text/unformatierter Text) oder auch dort der Dimensionstext bzw. Langtext.

Wenn Sie wirklich schnell schreiben konnen (10 Finger-System), dann können Sie wirklich erkennen, dass die Buchstaben mit einer gewissen Latenz hinterher- hinken. Diese Latenz ist nicht immer gleich - sie variiert.
Testen kann man das (wenn man nicht so schnell schreiben kann) indem man einen langen Text mit "backspace" löscht. Das geht nicht gleichmäßig - sondern auch hier mit Variierender Latenz. In der Regel trifft man die gewünschte Stelle im Text nicht - man löscht u.U. 1-3 Zeichen zu viel (wegen der Latenz).
Wir müssen hier eindeutig unterscheiden zwischen dem Erfassen (Laden von Sucheinstellungen, Datenklassen, Datenreferenzen etc.) von Daten egal an welcher Stelle und dem Arbeiten in einem bereits erfassten Datensatz, egal ob gespeichert oder nicht. Wenn ich es richtig verstehe, sprechen wir hier immer von dem Bearbeiten eines bereits erfassten Datensatzes innerhalb der Oberfläche. Sprich Ereignisse wie Makros, Validierungen, Aufrufe, Setzen von Feldwerten sind abgeschlossen.

Nehmen wir das genannte Beispiel auf. Es wird ein Dimensionstext eines Artikels innerhalb des MultidataEdit-Elementes geändert. An dieser Stelle findet nur eine Interaktion zwischen Eingabefeld in der Oberfläche und dem KeyInputEvent statt. Beim KeyInput-Event für Texteingabe in Feldern wie Dimensionstexten wird aber kein Ereignis welches eine Latenz erklären könnte ausgelöst, sondern erst beim Verlassen des Feldes.

Ich habe mir einmal in meiner Entwicklungsumgebung die Mühe gemacht, die Netzwerkgeschwindigkeit und sämtliche Ressourcen so stark zu reduzieren bis eine Latenz spürbar war. Diese war dann aber auch in allen anderen Bereichen wie Word etc. bemerkbar. Solange die Latenz auch nicht in Word etc. existiert, kann ich mir diese innerhalb Sage nicht erklären.

zu Punkt 1:
a.) Rewe startet mit ca. 12 Sekunden (vollständiges Regiezentrum, jedoch ohne Dashboard) deutlich schneller wie die Wawi (bei uns ca. 26 Sekunden bis Regiezentrum, ohne Dashboard).
Das mag auch an diversen Zusätzlösungen in der Wawi liegen. Aber auch ohne Zusatzlösungen besteht eine Differenz.
b.) die Stammdatenmasken "Kunden" und "Lieferanten" öffnen sich in etwa der gleichen Geschwindigkeit
die sonstigen Rewe- Masken (etwa Buchungserfassung oder Stammdaten-Sachkonten etc.) öffnen vergleichsweise zügig - und der Wechsel von Datensatz zu Datensatz erfolgt ohne störenden Verzug)
natürlich kann man das nicht mit den Wawi- Masken "Stammdaten-Artikel" oder "Verkaufsbelege bearbeiten" vergleichen weil es um andere Datenmengen geht - aber Reaktionszeit der genannten Rewe- Masken würde ich mir für die genannten Wawi-Masken wünschen.
Eventuell ein erster kleiner Step: Schauen Sie im Server Manager einmal bitte was im Bereich Logging Service bei Umfang der Protokollierung eingestellt ist: Hier reicht für ein Echtsystem aus meiner Sicht Critical oder None, solange keine Fehleranalyse ausgeführt wird.
Anschließend wäre dann auch jeder Punkt im Bereich der Verwaltung Schritt für Schritt durchzugehen, ob die Konfiguration für ihr System geeignet ist. Hier hilft dann nur ein gemeinsamer Termin mit Ihrem Fachhandelspartner oder eigenes Testen unterschiedlicher Einstellungen.

Dass der Start und auch das Arbeiten innerhalb der Masken in Rewe/Wawi unterschiedlich lange dauert ist normal, da einfach die Metadatenbasis im Bereich Rewe deutlich geringer ist, als die in der Warenwirtschaft. Aber das identische Dialoge mit der gleichen Konfiguration eine spürbare Latenz aufweisen, ist mir nicht bekannt. Hier läuft die komplett identische Logik auf identischer Metadatenbasis.

Der Wunsch aller Anwender ist jedoch: "kann man die Sage nicht etwas schneller / flüssiger machen"
Das gleiche höre ich von allen unseren Partnern mit der Sage 9.0.4.
Laut meinen ersten Eindrücken ist die Performance in der 9.05 innerhalb der Warenwirtschaftsdialoge deutlich besser geworden. Sage bemüht sich und tut hier etwas!

Für Vergleichswerte einmal: Bei optimalen Einstellungen komme ich in meiner Entwicklungs-VM nach dem Klicken auf Anmelden auf 7 Sekunden bis zum Laden des Regiezentrums der Wawi, 4 Sekunden für das erste Initialisieren der VK-Belegerfassung (nach dem Schließen und zweitem Öffnen ist keine Verzögerung bemerkbar) und auf 5 Sekunden für das Laden des Regiezentrums nach dem Klicken auf Anmelden im Rewe.

Mit der tempdb habe ich micht noch nicht beschäftigt (Kompatibilitätsgrad 130, 296MB )
Die tempdb kann in vielen Bereich ausschlaggebend sein. Es wird aber von Sage in den nächsten Wochen ein Leitpfaden zu der optimalen Einstellung eines SQL-Servers herausgegeben. Eventuell warten Sie auf diesen, dann spare ich mir die Tipparbeit ;-)

zu Ihren Schaubildern:
Ich habe diese nur zur Verdeutlichung der noch zur Zeit bestehenden Komplexität bei CRUD Operationen angehangen bis die Umstellung auf eine Access freie Version abgeschlossen ist. Anschließend wird auch noch die Umstellung auf 64 Bit erfolgen. Für den genannten Fall der Texteingabe siehe oben.

Ich hoffe ich habe nichts wichtiges übersehen. Beste Grüße Rouven
 
Vielen Dank für die Informationen Rouven,

die Logging- Einstellungen im Server Manager habe ich sofort umgesetzt - mal sehen ob das überhaupt spürbar ist.

Herr Ostermann hatte ja über Performance Optimierungen (Dienste-Konten vs. Lokales Systemkonto) und den SQL-Server Leitfaden gesprochen.
Und ja die 9.0.5 soll auch geringfügig besser sein.
Auf die Werte von deiner Entwicklungs- VM komme ich aber auch auf meiner (all in One-) Entwicklungsumgebung bei Weitem nicht.
Was hast du da für Hardware im Einsatz? und welches Betriebssystem / Hypervisor nutzt du für deine Entwicklungsumgebung?

Wie gesagt ich hätte gute Lust eine Sage- Installation auf einem guten virtualisierten Gaming- PC mit einem i9 oder Ryzen7 Prozessor durchzuführen.
Ich könnte mir vorstellen, dass Sage 100 damit performanter läuft als auf einem aktuellen Server- System mit einem Xeon-Gold oder Epyc 7003- Prozessor.

Ja - die Hoffnung stirbt zuletzt. Sage hat das Thema "Performance" wenigsten jetzt auf der Agenda. Vielleicht kommt dann die "göttliche Eingebung".

Dir jedenfalls herzlichen Dank für deine Ausführungen
 
Kein Problem.

SQL-Server Leitfaden gesprochen.
Genau, auf den bin ich auch gespannt.

Was hast du da für Hardware im Einsatz? und welches Betriebssystem / Hypervisor nutzt du für deine Entwicklungsumgebung?
Eigentlich nichts besonders und würde bestimmt auf lokaler SSD noch besser laufen.
- Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz 2.30 GHz mit 8 virtuellen Prozessoren
- 32 GB Ram
- Windows 10 Pro auf Microsoft Hyper-V
- Datenträger liegt extern auf einer Sandisk Extreme Portable 1050 MB/s
- Sage Server Einstellung sind allerdings nicht auf Standard

Und ja die 9.0.5 soll auch geringfügig besser sein.
Ja, dass kann ich aufjedenfall bestätigen. Ich würde sogar sagen bemerkbar besser, wenn ich es mit der 9.04.11 vergleiche auf identischen Voraussetzungen( wie oben genannt).

Ja - die Hoffnung stirbt zuletzt. Sage hat das Thema "Performance" wenigsten jetzt auf der Agenda. Vielleicht kommt dann die "göttliche Eingebung".
Hoffen wir das beste;-)

Beste Grüße Rouven
 
- Datenträger liegt extern auf einer Sandisk Extreme Portable 1050 MB/s
Könnte aber der Schlüssel hier sein weil ist ja externe NVME SSD zwar auch "nur" USBC (3.2+ ist schnell) aber viele Systeme da draußen haben schlechteres IO speziell wenn andere Shares/VMs oder sogar noch Backup in der Firma auf dasselbe NAS laufen.
 
Könnte aber der Schlüssel hier sein weil ist ja externe NVME SSD zwar auch "nur" USBC (3.2+ ist schnell) aber viele Systeme da draußen haben schlechteres IO speziell wenn andere Shares/VMs oder sogar noch Backup in der Firma auf dasselbe NAS laufen.
Das stimmt schon, aber gerade das sollte ja möglichst vermieden werden ;-)
 
Zurück
Oben