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...
 
also ich kenne eine Vielzahl größerer Sage Kunden die komplett ohne Zusatzlösungen auskommen.
 
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
 
Hört sich an als ob Locks (egal welche) eine art Krankheit sind.
Sie machen schon sinn (Transaktionen), deshalb gibt es sie.
Nur ist immer die Frage wieso das System hängt.
Dann schaut man halt auf offene Locks.
Muss aber nicht der Grund sein.
Ich forsche da selber noch.
 
Ich hab versucht die Firma HTK anzurufen, Serkan Güler zu erreichen, keine Antwort per Mail, gar nichts!
Hier wird man nur total verarscht!

*Abschnitt ebenfalls wegen Beleidigung gelöscht*

Anmerkung vom Admin:
um 18:20 Uhr haben die meisten IT-Firmen und auch andere geschlossen. Die Öffnungszeiten sind sowohl im Internet hinterlegt und werden sicher auch bei Anruf angesagt. Und auch Mails müssen nach Feierabend von Mitarbeitern nicht bearbeitet werden.
 
Zuletzt bearbeitet von einem Moderator:
Ich klinke mich aus dieser Diskussion aus (werde den Verlauf nicht mehr beobachten - und "Cyberlord" im Forum ignorieren)

Ich erkenne jedenfalls in "Also verarscht wem anderen ihr Idioten!" ein gewisses anhaltendes Niveau beim Verfasser.

Ich hoffe, dass Sie "Cyberlord" zukünftig nur noch auf SAP-Foren posten und das USER-Forum "sage-forum.de" nach Ihrem kurzen Gastspiel verlassen werden.

Ich wünsche Ihnen "Cyberlord" mit Ihrer freundlichen und inspirierenden Art und Ihrem überaus höflichen Umgang mit anderen Usern viel Erfolg in der SAP Welt.
 
ich greife hier mal moderierend ein - versuche ich sonst zu vermeiden.

wenn es in Ordnung ist lösche ich die ausfallenden und überflüssigen Kommentare.

Kurz zur Erläuterung für alle die es später lesen.

Eine gewisse "Netikette" wäre wünschenswert. Beleidigungen werden nicht toleriert.
 
Hallo Cyberlord,

vielen Dank für deine Rückmeldung. Ich möchte klarstellen, dass unsere Geschäftszeiten von 08:00 bis 17:00 Uhr sind und wir nur zusätzlich eine 24/7-Hotline anbieten, um auch außerhalb dieser Zeiten unterstützend zur Seite zu stehen. Diese ist, wie üblich bei Notdiensten, kostenpflichtig.

Wir haben bereits über persönliche Nachrichten kommuniziert, daher bin ich etwas überrascht über die Form deiner Kritik. Wenn du weiterhin Unterstützung benötigst und der Meinung bist, dass das Problem bei unserer Lösung liegt, empfehle ich dir, direkt unseren Support zu kontaktieren und ein offizielles Ticket zu erstellen. Dies ermöglicht es uns, deinen Fall gezielt und effektiv zu bearbeiten. Für eine detaillierte Prüfung ist es zudem wichtig zu wissen, welcher Anwender betroffen ist und ob ein gültiger Hotline- oder Wartungsvertrag besteht.

Unser Team besteht zur Hälfte aus Entwicklern, die bereit sind zu helfen, sollte tatsächlich ein Problem mit unserer Software vorliegen. Da du dich als Profi-Entwickler präsentierst, bin ich zuversichtlich, dass wir alle weiteren Diskussionen auf einer sachlichen und professionellen Ebene führen können.

Vielen Dank für dein Verständnis und deine Kooperation.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben