Sage Performance sehr schlecht

leider habe ich noch nicht so ganz verstanden was die Kritik ist - das die Performance langsam ist, dass manche Dinge Geld kosten oder das es nur Möchtegernprogrammierer gibt.

Ich selbst bin kein Programmierer. Habe mich aber gerade einmal auf ein Kundensystem verbunden, dessen IT-Berater ich für sehr fähig halte.

Besagter Kunde arbeitet mit der Sage 100, Sage HR Suite und Sage CRM.

Sage 100 sind in Summe 67 Benutzer. Die Datenbank beinhaltet Daten seit 2002.

Hier mal die harten Fakten bei den oft erfragten aber selten genannten Zahlen:

1. öffnen Adressstamm 14 Sekunden
jedes weitere öffnen <1 Sekunde

1. öffnen Artikelstamm 8 Sekunden
jedes weitere öffnen <1 Sekunde

1. öffnen Belegerfassung 6 Sekunden
jedes weitere öffnen <1 Sekunde

1. Speichern eines VK Beleg 4 Sekunden
1. Aufruf Druckvorschau 10 Sekunden
jedes weitere mal Speichern und Druckvorschau 2 Sekunden

Auf Wunsch kann ich das auch gerne jedem per Fernwartung zeigen.

Ich bin da ganz bei @cmayer - gerne Kritik, sachlich und konstruktiv.

Auch bei uns gibt es genug offene Wünsche an Sage ;-)
 
Die Allermeisten können den Beitrag von "Cyberlord" sicherlich ganz gut einschätzen.
Allen Anderen sei empfohlen sich dem Thema sachlich zu nähern.

Wenn Frust und Hilflosigkeit zu pauschaler Diffamierung führt ist Niemandem geholfen.

Es sind nicht die "Programmierer" der Sage- Developer- Partner, die für die Performance einer Sage- Installation verantwortlich zeichnen.

Vielmehr kann man durch eine kluge Wahl der DV-Infrastruktur und der entsprechenden Einrichtung dieser Infrastruktur der Sage 100 auf die Sprünge helfen, so dass ein akzeptables Arbeiten im produktiven Umfeld möglich ist.

Die Netzwerktechniker und Server- Administratoren sind hier gefragt - nicht die Entwickler und Programmierer.


Man kann Sage aus meiner Sicht zwei Vorwürfe machen:

1. Trotz diversen Dokumenten wie Leitfaden und Systemanforderungen gibt es keine klaren offiziellen Empfehlungen für eine geeignete performante Infrastruktur. Hier muss jeder Sage- Partner seine eigenen Erfahrungen sammeln / Wissen aufbauen.
Sage hat nicht erkannt, dass diese Wissenslücken direkt auf die Akzepanz der Sage 100 schlagen - Endanwender können nicht unterscheiden, ob es an der schlechten Infrastruktur oder dem Sage- System liegt. Frei nach dem Motto: "Sage 100 ist träge - folglich ist Sage 100 scheiße!"

2. Der Sage-App-Server und der aktuelle freigegebene Sage-Client sind noch immer nicht auf moderne Multi Core Systeme ausgelegt.
Das wurde viel zu lange hinausgezögert. Performance hatte bei Sage zu lange keine oder eine viel zu geringe Priorität. Man hat nicht verstanden, dass Akzeptanz auch mit der Performance zusammenhängt.
 
Zuletzt bearbeitet:
Wir haben bereits herausgefunden was die schlechte Performance verursacht.
Wir verwenden das Zusatzmodul HTK Autobelege.
Wenn dies ausgeführt wird, ist das komplette System für mind. 8 Minuten total blockiert.
Der Hersteller weiß bescheid, konnte jedoch seit 3 Wochen keine Lösung bieten.
Hinzu kommt, dass solche Blockierungen weitreichende Probleme bei anderen Bereichen verursacht.

Und ja, wir haben die stärkste Xeon-CPU:
Xeon e-2176G

Intel® Xeon® E-2176G Prozessor (12 MB Cache, bis zu 4,70 GHz) – Produktspezifikationen | Intel

Intel® Xeon® E-2176G Prozessor (12 MB Cache, bis zu 4,70 GHz) Kurzübersicht über Spezifikationen, Funktionen und Technik.
www.intel.de www.intel.de
4,7 GHz.

Extra nur für Sage einen eigenen ESX.

Also was machen WIR falsch?
Was macht Sage falsch?
Was kann JEDER in SEINEM Bereich besser machen?

Ich habe selber schon sehr viele Lösungen Programmiert, solche Probleme kenne ich bei meiner Software nicht.
 
Hallo Syberlord,

hört sich doch zielführend an, dass die Ursache in Ihrem Fall für die schlechte Performance herausgefunden wurde. So wie Sie beschreiben, ist es untypisch, dass die Systeme minutenlang blockiert werden. Zu den Zusatzmodulen kann jedoch nur der Hersteller des Zusatzmoduls Ihnen eine Info aufgrund Ihrer Systemgegebenheiten geben, daher werden Sie hier in diesem Forum dafür keine Sage-Spezifische Lösung finden.

Zum Thema Performance im Allgemeinen kann ich persönlich dem vorherigen Beitrag von @cmayer gänzlich zustimmen!

Lassen Sie Ihr System durch Ihren Fachhandelspartner prüfen... Die Performance ist kein allgemeines Problem von Sage100!

Beste Grüße
Sergej Müller
 
NEIN das ist komplett falsch.

Denn kein größeres Unternehmen kommt ohne Zusatzprogrammierungen aus.
Also betrifft es 100% der Sage-Kunden die größer sind.
Und von denen spreche ich ja.

Wir haben zwar nur 50 Mitarbeiter in der Auftragsabteilung, generieren jedoch um die 300 Belege pro Tag, wobei viele bis zu 200 Positionen haben.

Es haben schon einige "Spezis" draufgeschaut, hat nichts geholfen, dann habe ich mir das genauer angesehen und den Fehler gefunden und Lösungsansätze angeboten.
Nur bei der Umsetzung haperts dann natürlich auch wieder.

Wenns funktionieren soll muss man es selber programmieren...
 
Kann natürlich auch vorkommen.
Dann machen die aber was falsch.

Autobelege?
Logistik?
Beleganpassungen?
automatischer Belegdruck?
Shopanbindungen?

Sorry, aber ich rede von der Praxis und nicht von der Theorie.
 
Also ich muss sagen wir haben auch unter anderem HTK Autobelege und die funktionieren wunderbar. Wir haben auch mehr als 50 MA die mit der SAGE arbeiten und haben noch viele weitere Lösungen im Einsatz.
Bei uns machen die Autobelege keinerlei Probleme und auch wir machen täglich um die 1000 Belege.

SAGE ist an manchen Stellen sicherlich grundsätzlich was die Performance angeht nicht optimal aber im großen klappt es.

Meiner Meinung nach, muss man immer das Gesamtpaket betrachten wenn bei der Systemumgebung bei euch die Autobelege Probleme verursachen liegt es eventuell an einer Gesamtkonstellation von weiteren Lösungen und am Ende steigt es bei den Autobelegen aus.
Genau kann man das nun hier nicht weiter beurteilen. Allerdings finde ich es auch wenig sinnvoll mit einem "Hammer" um sich zu schlagen und zu sagen dass alle keine Ahnung haben :)

Aber wie @breithecker bereits erwähnt hat sollte sich am besten jeder selbst ein Bild machen.
 
Natürlich kann ich verstehen, dass es frustrierend ist, wenn es zu Performanceproblemen kommt. Aber es ist wirklich wichtig, die ganze Situation im Blick zu behalten, denn oft spielen verschiedene Faktoren eine Rolle, darunter wie unsere Lösung mit anderen Systemen zusammenarbeitet.

Wir haben auch größere Kunden, die täglich zwischen 2.000 und 8.000 Aufträge über diverse Shops und Marktplätze abwickeln und dabei auch unsere Autobelege verwenden. Diese Kunden sind in der Regel sehr zufrieden. Allerdings gab es auch Fälle, in denen Probleme auftraten, die durch äußere Umstände verursacht wurden. Manchmal waren es SQL-Trigger in der Dispotabelle, die sich gegenseitig störten, oder es waren eigene Lösungen von Kunden für Auswertungen, die gelegentlich die Belegtabelle blockierten.

Es gibt auch unter SQL-Entwicklern Diskussionen darüber, ob ein einfaches SELECT Befehl Tabellen und/oder nur Seiten sperrt. Meiner Erfahrung nach ist es so, dass SELECTs durchaus sperren können, was auch der Grund ist, warum es Befehlserweiterungen wie "nolock" und "read uncommitted" gibt.

Bei einem unserer Kunden verursachte beispielsweise das Aktualisieren eines Benutzerfeldes mit DCM Verzögerungen beim Speichern von Belegen, was die SQL-Transaktionen verlangsamte und manchmal zu Deadlocks führte. Ein anderer Kunde hatte Verzögerungen, weil ein SELECT auf eine überfüllte Tabelle ausgeführt wurde.

Deadlocks sind bspw. eine knifflige Angelegenheit, weil in solchen Fällen jede beteiligte Transaktion sowohl blockiert als auch blockierend sein kann. Es geht also nicht wirklich darum, wer „Schuld“ hat, sondern darum, wie man zusammen eine Lösung finden kann, beim Einsatz von diversen Lösungen.

Vielleicht gibt es aber auch eine neuere und optimierte Version Ihrer Lösung?

Kurz gesagt, es ist wichtig, das Ganze zu betrachten. Wenn Sie spezielle Probleme haben, zögern Sie bitte nicht, mir direkt eine Nachricht mit Ihrer Ticketnummer zu schicken. Ich schaue mir das gerne dann genauer an. Wir haben sowohl einen .Net Dienst als auch das Add-In „Autobelege“ im Portfolio und es wäre super, mehr über die eingesetzte Technik und Version zu erfahren, damit wir Ihnen besser helfen können.
 
Hallelulja!

Hört sich an ob da einer eine Ahnung hat, Gott sei dank!
Und ja, ich verwende wo es nur geht READ UNCOMMITTED für Auswertungen.
Und nein, eine SELECT sperrt nichts.
Und auch nein, bei einem SELECT auf eine große Tabelle, wenns viel Leistung braucht, sieht man sehr schön im Aktivitätsmonitor oder genauer im Profiler.

Ich schicke ihnen sehr gerne eine PM mit meinen Kontaktdaten.
Ich möchte mich schon vorher sehr herzlich für die nette Hilfe bedanken!
Man ist halt oft sehr verzweifelt.

lg
 
Ok. Gerne einfach melden. Auch sonst im Support, falls Sie mich nicht erreichen können.
Ich bin zwar kein Programmier-Experte, aber aus meiner Erfahrung kann ich sagen, dass ein einfacher SELECT-Befehl in MS SQL Server durchaus Sperren auf Tabellen oder Seiten auslösen kann. Dies hängt von der Isolationsstufe der Transaktion ab, in der der Befehl ausgeführt wird. Um solche Sperren bei Lesevorgängen zu vermeiden, gibt es ja die Möglichkeit, einen Zusatz wie NOLOCK oder die Isolationsstufe READ UNCOMMITTED zu verwenden. Diese sind nützlich bei SELECT-Befehlen, weil sie das Lesen von Daten erlauben, ohne dabei Sperren zu setzen – etwas, das bei INSERT-Befehlen ja auch nicht möglich ist sie zu verwenden. Das sorgt manchmal und sehr oft aber auch für Diskussionen, wie oben schon angedeutet :)
Aber wenn Sie generell immer READ UNCOMMITTED verwenden sollte das ja passen. Bei einem Insert und Update sollte man auch aufpassen und kann dann ggf. auch den Zusatz "Rowlock" verwenden. Das hatten wir mal auch vor kurzem. Da hat ein SQL Job mit Update auf die Belege-Tabelle, auch wenn das nur für eine BelID ausgeführt wurde, dafür gesorgt das die Ganze Tabelle gesperrt war. Hier mal eine kleine Erklärung aus dem Internet dazu:

"Standardmäßig kann der SQL Server entscheiden, Sperren auf unterschiedlichen Ebenen wie Zeilen-, Seiten- oder sogar Tabellenebene zu setzen, je nachdem, was das System für am effizientesten hält. Der Hinweis ROWLOCK weist SQL Server jedoch an, explizit Sperren auf der Ebene einzelner Zeilen anzuwenden."

Das kann ich noch als Tipp mitgeben.

LG
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben