Performance von Leistungssummen

1. offizieller Beitrag
    • Offizieller Beitrag

    Leistungssummen sind eine Möglichkeit in Vertec, Summenwerte in Bezug auf Leistungen performance- und memoryoptimiert berechnen zu lassen und diese so zu gruppieren, wie man das benötigt (z.B. nach Projekt, Tätigkeit, aber auch nach Rechnung oder Monat). Die Dokumentation finde sich in https://www.vertec.com/ch/kb/leistungssummen/.


    Diese SQL-basierten Abfragen sind gedacht um einmal, zu Beginn einer Auswertung, Daten zu berechnen und diese nachher weiter zu verwenden. Sinnvolle Anwendung finden sich in BI Generatoren, Office Berichte, bei der Abfrage von aussen über XML oder auch wenn man von einem Python Skript aus Daten exportieren will. So sind sie sehr performant und nützlich, weil sie auch die Businesslogik rund um Leistungen kapseln.


    Wir treffen jedoch vermehrt Anwendungen an, bei denen in einer Liste drin in vielen Spalten und für viele Zeilen solche Abfragen gemacht werden (so à là:

    self->groupleistungenB(varVon.asstring,varBis.asstring,'')->collect(minutenIntoffen+minutenIntverrechnet)->sum) dann ist das höchst ineffizient und langsam. Es werden tausende von SQL Abfragen abgesetzt, und je nach Performance des Servers und dem Netz kann das länger oder weniger lang dauern - auf jeden Fall wird es zu lange dauern.


    Die Vertec KB warnt davor, seit vielen Jahren: https://www.vertec.com/kb/leis…alten-von-leistungssummen. Da wir aber solche Customizations antreffen, wollte ich das Thema erneut aufgreifen. Auch ist die Thematik mit der Umstellung auf Unicode in Vertec 6.5 noch akuter geworden.

    Sie sprechen davon, das die Server Performance oder Netzwerk Performance eine Rolle spielt, für die Geschwindigkeit von Vertec. Dies kann ich mir durchaus vorstellen, nur:

    Ich habe ein Skript geschrieben, das enorm Zeitintensiv ist. Dies ist kein Problem, da es im Hintergrund läuft. Nur lastest es weder den Server, noch das Netzwerk oder die Festplatte aus. Wir verwenden die Firebird Datenbank. Wir sprechen da von ein paar Prozent CPU Last und ein paar Prozent vom RAM. Bei der Festplatte sah man nicht einmal eine erhöhte Aktivität.


    Wie können sie sich das erklären?

    • Offizieller Beitrag

    Wollen wir ein neues Topic starten? Ich wollte hier explizit über die SQL Performance im Zusammenhang mit Leistungssummen berichten.

    Bei Ihrem Skript wären die relevanten fragen:

    • welche App führt das Skript aus? Task Scheduler oder mit /script /batch gestartet?
    • was macht das Skript genau? Wenn CPU nicht ausgelastet ist wo das Skript ausgeführt wird dann ist die Frage, auf was da gewartet werden muss: LAN, Internet, externes API?

    Zu "CPU nicht ausgelastet" ist noch relevant zu wissen, dass die Vertec Session Singe Threaded ist, also nur einen CPU Core auslasten kann. Bei sehr vielen Cores kann das im total dann "mikrig" aussehen.

    Nein das wollte ich eigentlich nicht. Aber man merkt anhand ihrer bestimmten Antwort wie sensibel sie auf diese Thema sind...


    Ich wollte tatsächlich nur Fragen wo das Problem sein könnte, ohne Wissenschaftlichen Hintergrund. Fakt ist, Bei ist alles lokal. Ich bin tatsächlich fähig die einzelnen Cores anzuschauen. und keiner hat da auch nur annähernd einen Ausschlag geben. Aber Single Threaded erklärt natürlich einiges...


    Ich möchte das nicht weiterführen, wir sehen uns nächste Woche und können das untereinander besprechen. Ich gehe davon aus, das es wieder Thema Nummer 1 sein wird...

    • Offizieller Beitrag

    Es ist natürlich ohne weiteres möglich, sehr unperformante Dinge in Vertec zu customizen. Das wird sicher Thema sein in einer Woche, klar.


    Ich schlage daher eher vor, konkrete Fragen hier zu diskutieren und zu lösen. Man kann konkrete Performanceproblem nur konkret lösen, nicht allgemein - es gibt da keinen "Kill Switch". Wir sind aber sehr gerne bereit, uns das Skript und die Infrastruktur anzuschauen. Es gibt immer Potential. Machen Sie doch bitte einen neuen Thread mit den konkreten Angaben zur Infrastruktur und dem Skript, am besten gleich mit dem Code.

    Performance bei Vertec ist etwas, um das man sich aktiv kümmern muss. Es ist einfach, mit eigenen Konfiguration etc. Vertec langsam zu machen.
    Bei uns ist das ein ständiges "Dranbleiben" (wie beim Unkraujäten :)). Wenn wir ein Performance-Issue haben, schauen wir uns das im Detail an, analysieren die Ursache und versuchen Optimierungen durchzuführen. Neben einer performanten Server-Umgebung (für unsere > 2000 User) gibt es eben einige von uns gewünschten Listen, bei dem man Queries optimieren konnte.
    Bei uns hat es sich gelohnt, gewisse Listen auf SQL umzustellen. Und man bezahlt eben mit Performance wenn man in Listen umfangreichere Bewegungsdaten jedesmal und für jeden Eintrag "rechnen" lässt.
    In einem unserer Anwendungsfälle stellen wir den Usern zwei Listen zur Verfügung:

    1. "schnell" mit etwas weniger Detail. Details bekommt man dann schnell, wenn man einen Eintrag öffnet.
    2. "langsamer" mit (sehr) vielen Details wenn man wirklich alles auf einen Blick braucht

    Die user haben die Wahl: Und wenn man eben die "langsame" List in diesem Fall braucht, startet man die Liste und holt sich parallel zum Aufbau einen Kaffee.