AvERP - Performance/Geschwindigkeit

[GraspGG]

Hallo werte Community, Mods und Admins,

wir haben die vergangenen Tage versucht zu ermitteln wie wir die Geschwindigkeit bzw. Performance von AvERP erhöhen können. Die SuFu lieferte dazu auch einige Hilfestellungen, welche bis auf den reinen Clientstart jedoch zu keinerlei Veränderungen führten.

Dem entsprechend knüpften wir uns den Server vor: der erste Schritt lag darin, den Server mit einem Raid-Controller zu versehen und entsprechend schnellere SATA Festplatten zu verwenden. Messungen ergaben mit 65MBit mehr als doppelt so hohe Transferraten wie zuvor mit der UDMA-Harddisk, was auf eine schnellere Antwortzeit von AvERP hoffen ließ - entgegen unserer Vermutung änderte sich die Performance durch Installation der Firebird-Datenbankanwendung als auch der Datenbank selbst auf der schnelleren Festplatte nicht mal um Nuancen!

Als nächstes betrachteten wir die Prozessorauslastung des Servers während Abarbeitung der drei unserer "Messumgebung" entsprechenden Schritte:
• Start des Clients auf einem Remote-Rechner: 15 Sekunden ab Anmeldung
• Aufruf des Artikelstamms: 10 Sekunden bis zur Suchmaske
• Wechseln zum Anzeigemodus (X): 20 Sekunden bis zur Anzeige der Artikelauswahl

Hierbei fiel uns gleich auf, dass der Server bis auf einen einzigen Peak unmittelbar vor der Artikelauswahl- Anzeige (Schritt 3) quasi Däumchen drehte.

Auf Grund dieser Erkenntnis wiederholten wir das vorangegangene Szenario bei gleichzeitiger Betrachtung der Client-Prozessauslastung, und wunderten uns nicht wenig, dass der Client während aller drei Schritte nahezu 100% der Prozessorleistung beanspruchte, und zwar so gut wie über den gesamten Zeitraum von Anmeldung bis zur Anzeige der Artikelauswahl!

Weitere Client-Tests bestätigten, dass in der derzeitigen 1 Benutzer AvERP-Umgebung lediglich die Client-Konfiguration Auswirkungen auf die Arbeitsgeschwindigkeit von AvERP hat: Je schneller bzw. performanter der Client, desto schneller arbeitet AvERP.

Als Referenz für die vorgenannte 3 Schritte Messumgebung haben wir folgenden Rechner verwendet:
IBM ThinkPad Notebook, Intel Pentium M 1.8GHz, 2GB RAM, 1GBit Netzwerk-Anbindung

Die Frage die sich uns nun aufdrängt: wieso benötigt der Client 45 Sekunden unter Volllast um sich anzumelden und den Artikelstamm im Anzeigemodus aufzurufen? Wie sieht diese Performance in einer Mehrbenutzer-Umgebung aus?

Hat vielleicht jemand ähnliche Erfahrungen gemacht und die Geschwindigkeit bei gleichbleibender Hardwarekonfiguration erhöhen können? Oder gibt es ggf. andere Vergleichswerte?

Vielen Dank schon vorab für jede Form von Hinweisen, Tipps und Feedback,

Liebe Grüße,
GraspGG

[martin.h]

Hallo

ich habe bei uns folgendes festgestellt:

der Start von AVERP auf dem Client ist wirlklich sehr langsam,
hier haben neue Exe unsw. zuletzt nichts gebracht.

was aber zuletzt eine spürbare Geschwindigkeit im Betrieb
(nach der o.g. langen Startzeit) der Clients gebracht hat, ist, neben der Funktion "Masken im Speicher halten" vorallem folgendes gewesen:

der Server hat mehr Hauptspeicher bekommen
(wir haben einen Win2008 64 bit Server exclusiv für die Fibu (Datev) und Averp auf einem VM-Ware ESX eingerichtet, hatten dieser Maschine (der WINServ) aber nur logisch 2 GB Hauptseicher spendiert. Der Sprung auf 4 GB war hier in der Geschwindigkeit doch recht deutlich verbessert.
objektiv gemessen haben wir es aber nicht.

[admin]

Wann war das letzte Restore der Datenbank?

Läuft die GarbageCollection?

Was sagt der Header der Datenbankstatistik (bitte posten)?

Langsamer Start von AvERP: Bisher ausschließlich (!) auf Anti-Virenprogramm zurückzuführen. Normaler Start sollte 5 bis 10 Sekunden dauern (schnellste bislang gesehene waren 2 Sekunden).

Neueste exe verwenden (Maskenöffnung stark verbessert, siehe andere Threads).

Wie viele Personen arbeiten auf der Datenbank gleichzeitig?

Auf dem Screenshot ist die Größe der Pages (Page size) ersichtlich, nicht aber die Anzahl der Pages...

[jo]

....

[martin.h]

Wann war das letzte Restore der Datenbank?

Läuft die GarbageCollection?

Was sagt der Header der Datenbankstatistik (bitte posten)?

Langsamer Start von AvERP: Bisher ausschließlich (!) auf Anti-Virenprogramm zurückzuführen. Normaler Start sollte 5 bis 10 Sekunden dauern (schnellste bislang gesehene waren 2 Sekunden).

Neueste exe verwenden (Maskenöffnung stark verbessert, siehe andere Threads).

Wie viele Personen arbeiten auf der Datenbank gleichzeitig?

Auf dem Screenshot ist die Größe der Pages (Page size) ersichtlich, nicht aber die Anzahl der Pages...

Restore gabs es noch keines, bei uns arbeiten derzeit nie mehr als 3 gleichzeitig am System und es gibt bislang erst einige dutzend Vorgänge wie Lieferscheine / Rechungen/Bestellungen und noch keine 1000 Artikel.

Virenprogramme: welche sind denn bekannt als problematisch und ggf. welche spezifischen Einstellungen, und sind es die am PC lokalen, oder ev. solche die am Server arbeiten?

Neuese EXE ist drin. 4216

Was sagt der Header der Datenbankstatistik -> wo findet man den? so tief stecke in da nicht drin.

[admin]

Ein Restore baut die Indizes neu auf. Wie ein Index aufgebaut ist, hängt von den Daten ab. Durch ein Restore bauen sich die Indizes neu auf. Derzeit arbeiten Sie quasi ohne einen brauchbaren Index.

Bitte Backup und Restore durchführen.

Header der Datenbank ist bei so wenigen Daten und Anwendern nicht relevant. Anzusehen wäre dieser in IBExpert, Datenbankstatistik.

Auf dem Server sollte gar kein Virenprogramm laufen.

Auf den Clients hatten wir bislang nur Probleme beim Start von AvERP.

[thorsten.grundei]

Hallo,

bei uns hat es eine Performanceverbesserung von Faktor 2 gegeben, als wir den Firebird Server von unserem Windows 2003 Server auf einen Windows XP Rechner gebracht haben. (Auf dem 2003 Server läuft bei uns eine Microsoft SQL Datenbank und ein Active Directory).

Zu den Virenscannern: Netwerk Scans ausschalten. Und einmal testweise den Virenscanner auf dem Rechner abschalten, auf dem die Firebird Datenbank läuft.

Ach so: Wenn noch die Firebird 1.x läuft, möglichst einen Rechner als Server nehmen, der einen hohen Prozessortakt hat. (Mehrkern Maschine bringt nichts, da die Datenbank 1.x sowieso nur einen Kern nutzt.

Gruss
ThorstenGrundei

[Gast]

[...]

Ach so: Wenn noch die Firebird 1.x läuft, möglichst einen Rechner als Server nehmen, der einen hohen Prozessortakt hat. (Mehrkern Maschine bringt nichts, da die Datenbank 1.x sowieso nur einen Kern nutzt.

Gruss
ThorstenGrundei

Hallo,

das ist so nicht ganz richtig: Wird Firebird als ClassicServer statt als SuperServer ausgeführt, so werden für jede Datenbankverbindung eigene Prozesse gestartet. In der Version als SuperServer soll der Prozess nur über Threads skalieren, was bis jetzt aber noch nicht vernünftig arbeitet.
Mehrkernprozessoren sind bei entsprechender Anwendergröße also durchaus sinnvoll.
Wir setzen z.B. auf den Classic Server Ver. 2.1 auf einem 64-Bit Ubuntu mit 8 Kernen und 8 GB Arbeitsspeicher. Und das skaliert wunderbar mit unserer Anwenderzahl (ca. 40).
Wenn ich mir vorstelle statt z.B. 8 Kerne a 2.6GHZ nur 1 Kern mit 3.3GHZ zu haben... das wäre nicht machbar.

Kurzum: Man muss hier also wirklich stark differenzieren und das auf die jeweiligen Bedingungen auslegen.

[miboe]

So ich muß jetzt auch mal noch was dazu schreiben ... ein Bekannter (in dienstlicher und privater Hinsicht) beginnt damit sich mit Averp anzufreunden und will es eventuell sogar bei sich einführen. Vor diesem Hintergrund habe ich den Thread hier natürlich mit ein bißchen Bauchweh verfolgt, weil er bei unserem System insbesondere immer von der Performance begeistert war.

Ich habe mit den Demodatenbanken in den Versionen 2006.B2.02, 2007, 2009.A09 und 2010.B07 mit den Exe's 4.2.1.12 und 3.6.0.15 jeweils mal Tests gemacht und da sind mir seltsame Dinge aufgefallen, die vielleicht bei der Optimierung weiterhelfen können:

Gestestet habe ich
* den Programmstart
* den Erstaufruf von Artikelstamm, Arbeitsstammplan, Stücklistenkopf, Bestellungen und einigen kleinen Masken mit wenig Intelligenz
* das Auslösen der Suche im Artikelstamm nach Erstaufruf der Maske mit dem roten Kreuz (also den Worst-Case Suchfall "zeig mal alles")

In jeder Version und mit jeder Exe vorher ein kompletter Rechnerneustart, also immer schön alles wieder auf Anfang.

Aufgefallen ist mir:
* der Programmstart dauert in der Tat mit ansteigender Datenbankversion immer länger, hier konnte ich allerdings deutliche Verbesserungen durch das komplette Löschen "überflüssiger" Systemsprachen erreichen. Der Anwender hat insbesondere mit höher werdender Datenbankversion immer länger den Spruch "Objekte werden registriert" vor der Nase. Die exe-Version hat darauf gefühlt wenig bis keinen Einfluß

* der Erstaufruf der Masken unterscheidet sich nur unwesentlich zwischen den Datenbankversionen. Bis auf den Artikelstamm. Dessen Ladezeit beim Erstaufruf der Maske wird nach meinem Geschmack ab Version 2009 eigentlich völlig inakzeptabel. Die kleinen Masken zeigen überhaupt keinen Unterschied (zumindest nicht ohne Stopuhr)
--> FAZIT: die Performance der Artikelstammmaske leidet derzeit irgendwie deutlich. Das wäre doch mal eine Prüfung wert. Ich persönlich finde die Maske mittlerweile auch sehr überfrachtet, den Reiter 8 mit der ÜBersicht könnte man sich sparen angesichts des Buttons zum Direktaufruf des Info-Systems

* das Auslösen der Suche im Teilstamm ist nur unwesentlich von der Version der Datenbank abhängig. Hier gibt es dann aber plötzlich einen deutlichen Unterschied zwischen den exe-Versionen. Während die 3.6.0.15 das normale Verhalten zeigt, nimmt sich die 4.2.1.12 kurz vor der Anzeige der Datensätze nochmal eine gehörige Auszeit, in welcher zum einen die Statuszeile der Maske komplett verschwindet und z.T. Menü und Icons der Maske weiß werden. Hier liegt also auch was im Argen

Grundsätzlich war ich allerdings wie auch einige Vorgänger von der extremen Differenz zwischen Ibexpert und dem Frontend von Averp erstaunt. Wenn man im Ibexpert in der V_BSA sich die Daten anzeigen läßt, vergehen nur Sekundenbruchteile, bis man alle Datensätze vor sich hat. Und zwar unabhängig von der Datenbankversion.
--> Fazit: hier geht einiges an Performance der Datenbank an sich wohl in der Kommunikation zwischen Frontend und Firebird flöten.

Vielleicht kann ja jemand mit den ganzen Infos was anfangen und uns nochmal voran bringen in Sachen Performance.

Viele Grüße
Michael

[admin]

* der Programmstart dauert in der Tat mit ansteigender Datenbankversion immer länger.

Richtig. Das ist auch so gewollt. Hintergrund: Lieber am Anfang 20 Sekunden bis zum Start warten als bei jeder Maske 1 Sekunde länger.

Hintergrund ist auch, dass mehr und mehr an Features hinzukommt. Mittlerweile ist ja FastReport 4, Pivot Cube, IBDAC als IBObjects-Ersatz und vieles mehr enthalten.

* der Erstaufruf der Masken unterscheidet sich nur unwesentlich zwischen den Datenbankversionen. Bis auf den Artikelstamm. Dessen Ladezeit beim Erstaufruf der Maske wird nach meinem Geschmack ab Version 2009 eigentlich völlig inakzeptabel. Die kleinen Masken zeigen überhaupt keinen Unterschied (zumindest nicht ohne Stopuhr)
--> FAZIT: die Performance der Artikelstammmaske leidet derzeit irgendwie deutlich. Das wäre doch mal eine Prüfung wert. Ich persönlich finde die Maske mittlerweile auch sehr überfrachtet, den Reiter 8 mit der ÜBersicht könnte man sich sparen angesichts des Buttons zum Direktaufruf des Info-Systems

Geprüft in Bezug der Geschwindigkeit wird unsererseits sehr viel. Der Artikelstamm ist auch mittlerweile wieder schnell. Das Problem kommt von anderer Stelle. Pro Feld in einer Maske müssen die Rechte geprüft, die Übersetzungen geholt und die Positionierung bzw. Farbe etc. bestimmt werden. Pro Feld dauert das, je nach Rechner, 8ms bis 15ms. Bei 200 Feldern (Artikelstamm) kommt man dann schon auf 3 Sekunden.

Um dem Abhilfe zu schaffen, wurde ja die "Maske im Speicher halten"-Funktionalität geschaffen.

Dazu kommt noch der Aufbau der mittlerweile zahlreichen Grids. Aber auch hier haben wir einen schnellen Weg geschaffen, der jetzt in jede Maske einfließen wird.

* Das Auslösen der Suche im Teilstamm ist nur unwesentlich von der Version der Datenbank abhängig. Hier gibt es dann aber plötzlich einen deutlichen Unterschied zwischen den exe-Versionen. Während die 3.6.0.15 das normale Verhalten zeigt, nimmt sich die 4.2.1.12 kurz vor der Anzeige der Datensätze nochmal eine gehörige Auszeit, in welcher zum einen die Statuszeile der Maske komplett verschwindet und z.T. Menü und Icons der Maske weiß werden. Hier liegt also auch was im Argen

Ist soweit eigentlich auch wieder auf dem alten Stand (v4.2.2.2).

Grundsätzlich war ich allerdings wie auch einige Vorgänger von der extremen Differenz zwischen Ibexpert und dem Frontend von Averp erstaunt. Wenn man im Ibexpert in der V_BSA sich die Daten anzeigen läßt, vergehen nur Sekundenbruchteile, bis man alle Datensätze vor sich hat. Und zwar unabhängig von der Datenbankversion.
--> Fazit: hier geht einiges an Performance der Datenbank an sich wohl in der Kommunikation zwischen Frontend und Firebird flöten.

AvERP bereitet die Daten besser auf als IBExpert. Man denke alleine an die Übersetzungen, Zusatzfunktionen usw. Trotzdem führt eine Suche in der Rechnung mit anschließender Datenübersicht (Strg+S & Strg+W) zu einer Auflistung aller Rechungen in unter einer Sekunde. Das ist doch okay.

[miboe]

Richtig. Das ist auch so gewollt. Hintergrund: Lieber am Anfang 20 Sekunden bis zum Start warten als bei jeder Maske 1 Sekunde länger.
Hintergrund ist auch, dass mehr und mehr an Features hinzukommt. Mittlerweile ist ja FastReport 4, Pivot Cube, IBDAC als IBObjects-Ersatz und vieles mehr enthalten.

Völlig okay ... und jetzt gibt es dafür sogar eine für jeden nachlesbare Erklärung Und wie eigentlich zu erwarten, liegt es daran, daß es im Leben nix für nix gibt. Ich glaube, die User sind auch nicht wegen der Wartezeit an sich verstört, sonder weil in der Phase "Objekte werden registriert" so lange nix passiert. Wenn sich ein Fortschrittsbalken nur Sekundenbruchteile nicht bewegt, ist er sicher kaputt

Geprüft in Bezug der Geschwindigkeit wird unsererseits sehr viel. Der Artikelstamm ist auch mittlerweile wieder schnell. Das Problem kommt von anderer Stelle. Pro Feld in einer Maske müssen die Rechte geprüft, die Übersetzungen geholt und die Positionierung bzw. Farbe etc. bestimmt werden. Pro Feld dauert das, je nach Rechner, 8ms bis 15ms. Bei 200 Feldern (Artikelstamm) kommt man dann schon auf 3 Sekunden.

Um dem Abhilfe zu schaffen, wurde ja die "Maske im Speicher halten"-Funktionalität geschaffen.

Dazu kommt noch der Aufbau der mittlerweile zahlreichen Grids. Aber auch hier haben wir einen schnellen Weg geschaffen, der jetzt in jede Maske einfließen wird.

An der Stelle war mir übrigens auch aufgefallen, daß man gerade den Artikelstamm spürbar dadurch beschleunigen kann, daß man z.B. nicht benötigte Systemsprachen einfach komplett löscht. Vielleicht wäre es ja mal einen Denkansatz wert, daß ihr die Systemsprachen in den Mastertabellen "vorrätig haltet" und nur diejenigen davon wirklich in die Sprachtabellen übertragen werden, die der User auch braucht. Damit wäre die Updatesicherheit gegeben und gleichzeitig die Performance der Mehrsprachigkeit verbessert. Es gibt/gab ja sowieso schon das Konzept der Mastertabellen in den A_... Systemtabellen

Ist soweit eigentlich auch wieder auf dem alten Stand (v4.2.2.2).

Jetzt muß ich mal kurz maulen: was nützt mir das ohne die 4.2.2.2, welche im Downloadbereich noch nicht verfügbar ist

AvERP bereitet die Daten besser auf als IBExpert. Man denke alleine an die Übersetzungen, Zusatzfunktionen usw. Trotzdem führt eine Suche in der Rechnung mit anschließender Datenübersicht (Strg+S & Strg+W) zu einer Auflistung aller Rechungen in unter einer Sekunde. Das ist doch okay.

Wie gesagt, war es ja auch hauptsächlich der Artikelstamm, der sich so deutlich in der Suchgeschwindigkeit unterschied. Die Masken mit den Bewegungsdaten waren weniger auffällig. Und natürlich ist eine gewisse Differenz zwischen IBexpert und Averp normal, aber bei der V_BSA war es halt super deutlich. Und in eurer Antwort war auch wieder die baustelle "Übersetzung" drin. Siehe den Vorschlag oben ...

Gruß
Michael