Problem mit Performance bei Rechnungseingänge

Allgemeine Diskussionen um die ERP Software AvERP

Moderator: SYNERPY

Antworten
miboe
Beiträge: 1295
Registriert: Fr Jul 28, 2006 9:13 am

Problem mit Performance bei Rechnungseingänge

Beitrag von miboe »

Hallo zusammen,

wir haben jetzt Averp seit drei Monaten live am laufen und sind letzte Woche über ein kleines Performance-Problem gestolpert, bei dem ich Hilfe bräuchte.

Folgendes Szenario:
Offene und gedruckte Bestellung mit 201 Positionen (!)

Wie üblich wurde dazu der Wareneingang erfaßt, ausnahmsweise wurden alle 201 Positionen in einer Lieferung geschickt. Das ist selten, im Regelfall werden so große Bestellungen von den Lieferanten "zerlegt", was aber meistens auch okay ist. Der Wareneingang hat keine Probleme gemacht, Rechenzeit waren irgendwas zwischen 2-4 Minuten, wobei dabei die Fertigmeldung schon mit dabei war. Das ist zwar lang, aber angesichts dessen was dabei ja alles in der Datenbank abläuft (Mengenabgleiche, Lagerbuchungen etc.) völlig okay.

Erwartungsgemäß kam dann aber auch die Rechnung an einem Stück zu diesem Wareneingang, weswegen dann die Erfassung der Positionen auch über die Auswahl "Nach Wareneingang" gemacht wurde. Alles wie gewünscht: auf die erste Position des WE doppelklick, alle 201 Positionen werden markiert und dann das Fenster per Datenübernahme verlassen ==> über eine Stunde Stillstand!

Das war dann nicht mehr so okay :( deswegen die Frage: Ist das normal und müssen wir damit leben oder kann man da irgendwas optimieren? Ein Vergleich mit einer kleineren Rechnung mit 70 Positionen sieht auch nicht viel besser aus, da nimmt sich das System knapp über 20 Minuten Auszeit. Das verleitet den User, der den Effekt nicht kennt natürlich zu der gefährlichen Annahme, daß das System sich weggehängt hat und dann kommt der Griff zu STRG-ALT-ENTF und das ist nicht gut ...

Ich hoffe, da kann mir jemand helfen
Michael
Nur wer das Unmögliche versucht, wird das Machbare erreichen!
--
Datenbank: 2012-A02
Programm: 4.2.5.65
OS: Win 7 Pro / Ubuntu 10.04.3
admin
Site Admin
Beiträge: 2673
Registriert: Di Feb 10, 2004 5:48 am
Wohnort: Bayreuth

Beitrag von admin »

:?: :?: :?:

Nein, dazu kann / darf / muss es auf keinen Fall kommen.

Ich hab das bei uns gerade mit einer Kundendatenbank durchgespielt:

AMD 3200+ Server mit RAID 01, 2Gb Speicher.
2,5 Gb Datenbank mit 200.000 Bestellpositionen.
Datenbank frisch geöffnet, also noch ungecached.

40 Positionen in WE erfasst.

+- 5 Sekunden

40 Positionen in RE erfasst.

+- 5 Sekunden

Wie schon anfangs erwähnt: :?: :?: :?:
miboe
Beiträge: 1295
Registriert: Fr Jul 28, 2006 9:13 am

Beitrag von miboe »

Hm ... hätten Sie trotzdem irgendeine Idee woran das liegen könnte? In dem Bereich der Datenbank haben wir wirklich gar nichts geändert, sondern alles "as is" übernommen, weil es allen Usern gefallen hat.

Wenn Sie mir wenigsten einen Fingerzeig in die richtige Richtung geben könnten, wäre das schon gut, sonst muß ich ja wirklich völlig im Trüben fischen. Es macht auch keinen Unterschied, ob sich ein normaler User anmeldet oder ob der SYSDBA das macht.

Gab es in den exe's irgendwelche Änderungen, die sich darauf auswirken könnten? Wir haben noch "relativ" alte Versionen, siehe im Thread wegen des Universalimport. Oder gibt es in der firebird.conf irgendwelche Tricks. Welches Serverbetriebssystem haben Sie denn? Bei uns tauchen die Probleme sowohl auf den normalen Live-Server (Win Server 2003) als auch auf dem Entwicklungsrechner (XP-Home SP2) auf.

Danke
Michael
Nur wer das Unmögliche versucht, wird das Machbare erreichen!
--
Datenbank: 2012-A02
Programm: 4.2.5.65
OS: Win 7 Pro / Ubuntu 10.04.3
admin
Site Admin
Beiträge: 2673
Registriert: Di Feb 10, 2004 5:48 am
Wohnort: Bayreuth

Beitrag von admin »

Das ist relativ schwer zu sagen. Mit der exe hat das höchstwahrscheinlich nichts zu tun. Das läuft bei der Aktion alles datenbankseitig. Ich weiß auch nicht, welche Version bei euch im Einsatz ist. Im Lagerwesen hat sich einiges getan, was die Performance verbessert...
miboe
Beiträge: 1295
Registriert: Fr Jul 28, 2006 9:13 am

Beitrag von miboe »

Datenbank ist die 2006.B2.02 mit den Skripten aus dem Skriptpaket soweit sie noch nicht in der Datenbank downloadseitig drin waren. Es wurden also hauptsächlich die Skripte aus Juni und Juli 2006 nachträglich eingespielt.

Die Averp.exe ist die 2.0.0.8, Averpstart 2.0.0.1

Kann das irgend wie an den Datenstrukturen liegen, daß wir da beim Importieren der Daten was falsch gemacht haben? Vorstellen kann ich mir das zwar nicht, weil alles andere eigentlich sauber (und schnell) funktioniert, aber man weiß ja nicht...

Gruß
Michael
Nur wer das Unmögliche versucht, wird das Machbare erreichen!
--
Datenbank: 2012-A02
Programm: 4.2.5.65
OS: Win 7 Pro / Ubuntu 10.04.3
miboe
Beiträge: 1295
Registriert: Fr Jul 28, 2006 9:13 am

Beitrag von miboe »

Noch zwei Ideen:

* Kann das an der Verwendung von ActiveDirectory liegen?
* Oder an dem Dateinamen Problem gemäß den Firebird Release Notes? Also diese Sache mit *.fdb anstatt *.gdb verwenden wegen des System Restore unter Windows XP aufwärts?

Letzteres werde ich jetzt gleich mal auf dem Entwicklungsrechner testen ... und dann hier berichten

Gruß
Michael
Nur wer das Unmögliche versucht, wird das Machbare erreichen!
--
Datenbank: 2012-A02
Programm: 4.2.5.65
OS: Win 7 Pro / Ubuntu 10.04.3
admin
Site Admin
Beiträge: 2673
Registriert: Di Feb 10, 2004 5:48 am
Wohnort: Bayreuth

Beitrag von admin »

ActiveDirectory und den Dateinamen kann man ausschließen, wenn der TaskManager eine 100%ige Auslastung für Firebird anzeigt.
miboe
Beiträge: 1295
Registriert: Fr Jul 28, 2006 9:13 am

Beitrag von miboe »

STimmt, die Änderung der Dateiendung hat nur den ERSTEN Datenbankstart deutlich beschleunigt unter XP. Genau das ist auch in den Firebird Releasenotes beschrieben.

Ich habe die Bestellung mit den 200 Positionen mal als Duplikat in der Testdatenbank komplett neu von Hand eingegeben um auszuschließen, daß vielleicht die bestehenden Daten einen Hau weg haben. :roll: Danach dann wieder den Wareneingang nach Bestellung erfaßt.

==> 60-90 Sekunden, einmal sogar fast 120 Sekunden

Datenbank schließen, wieder öffnen, damit ich im Leeren Cache arbeite. WE fertiggemeldet:

==> wieder genau so lang gedauert wie das Erfassen

An der Stelle drängt sich dann der Verdacht auf, daß es am Lagerbuchungsprotokoll liegen könnte, weil ja sowohl beim Erfassen als auch beim Fertigmelden pro Position ein oder zwei Einträge in BARTLHBU gemacht werden. Ansonsten passiert ja beim Fertigmelden nicht viel, beim Erfassen hingegen werden ja auch noch die gesamten Datensätze in BLLCP erzeugt. So sieht es zumindest mal aus wenn man mit auf 0 gesetztem GEN_ENTWICKLUNG in die A_WASMACHTIB schaut.

Danach wieder Datenbank zugemacht komplett abgemeldet und wieder angemeldet. Dann den Rechnungseingang erfaßt und wieder das gleiche Problem, wie ganz am Anfang beschrieben ... wenn das so bleibt, töten mich unsere Anwender, die mich Rechnungen zu tun haben. Es ist wie gesagt nicht die Regel, daß wir solche Mordsrechnungen haben, aber Rechnungen zwischen 40-60 Positionen sind normal, und da ist halt eben auch 20 Minuten Stillstand. Auch hier erkennt man also einen linearen Zusammenhang zwischen Anzahl Datensätze und Stillstand.

Würde es was nützen, wenn ich mal eine Datenbank zum reinschauen zur Verfügung stelle? Sei es per Post auf CD oder wie auch immer ...

Ich brauche echt einen guten Tip an der Stelle
Michael
Nur wer das Unmögliche versucht, wird das Machbare erreichen!
--
Datenbank: 2012-A02
Programm: 4.2.5.65
OS: Win 7 Pro / Ubuntu 10.04.3
admin
Site Admin
Beiträge: 2673
Registriert: Di Feb 10, 2004 5:48 am
Wohnort: Bayreuth

Beitrag von admin »

Klingt wirklich nach dem Lagersystem. Hier haben wir einiges verändert, so dass es jetzt sehr viel schneller ist. Wie viel habt ihr denn selber verändert, sprich: Würde ein Update Sinn machen?
miboe
Beiträge: 1295
Registriert: Fr Jul 28, 2006 9:13 am

Beitrag von miboe »

Nun, der größte Brocken, der wirklich ein Update war, war wohl der Wareneingang, den ich ja mal hochgeladen hatte. Ansonsten halt einige Masken und Views angepaßt, Druckformulare etc. Es ist alles was wir geändert haben sauber dokumentiert, wobei gerade bei den Masken und Reports es ja nur das Laden der *.res im Designer wäre. Ich muß mal in Ruhe nachschauen.

Ich hatte auch schon versucht, mit Hilfe des Averptransfer aus der letzten Alpha (Struktur) und unserer Testdatenbank (Daten) eine neue Datenbank zu erzeugen, bekommen aber Fehlermeldungen, daß er das GBAK nicht finden / ausführen könnte :?: GBAK an sich funzt aber auf unseren Systemen.

Ich bin jetzt eine Woche zumindest was Averp anbelangt "computerlos" und werde mich wohl erst am nächsten Wochenende wieder drum kümmern können. Ich werde dann als Test evtl. mal versuchen, diese 200 Positionen Bestellung in der 2007alpha nachzubauen. Vielleicht kann ich die Stammdaten ja mit dem IBexpert rüberziehen, dann brauche ich nicht alles von Hand zu machen.

Gruß und Danke
Michael
Nur wer das Unmögliche versucht, wird das Machbare erreichen!
--
Datenbank: 2012-A02
Programm: 4.2.5.65
OS: Win 7 Pro / Ubuntu 10.04.3
miboe
Beiträge: 1295
Registriert: Fr Jul 28, 2006 9:13 am

Beitrag von miboe »

Nachtrag:

Im gesamten Bereich Lagerwesen, Lagerbuchung, Rechnungswesen eingehend und ausgehend haben wir überhaupt nichts geändert. Nur die WE-Prüfung, wie gesagt

Gruß
Michael
Nur wer das Unmögliche versucht, wird das Machbare erreichen!
--
Datenbank: 2012-A02
Programm: 4.2.5.65
OS: Win 7 Pro / Ubuntu 10.04.3
miboe
Beiträge: 1295
Registriert: Fr Jul 28, 2006 9:13 am

Beitrag von miboe »

Ich habe die Ursache für die mangelnde Performance gefunden:

Beim Erfassen der Rechnungspositionen wird jedes mal wenn eine Position hinzukommt ja der Trigger BLRC_BU0 ausgelöst. Dieser ruft dann seinerseits die P_BLRC_VERTEILEN auf, welche die Nebenkosten auf die Positionen verteilt ... und das halt 201 mal nacheinander. Bei jeder Neuberechnung der Umlage erfolgt aber ein UPDATE auf die bis dahin bereits angelegten Positionen in BLRCP, was dann wiederum den ganzen Trigger-Schwanz auslöst, samt INSERT in BARTLHBU usw.

Ergebnis: Zum Erfassen von 201 Positionen im Rechnungseingang werden 20600 Buchungen im Lagerbuchungsprotokoll erzeugt. Da ist es kein Wunder, daß da nix mehr geht!

Die Lösung ist erstaunlich einfach, auch wenn der User etwas mitdenken muß: Man setzt in BLRC_BU0 die Aufrufbedingung für P_BLRC_VERTEILEN so, daß auch wirklich nur dann Nebenkosten verteilt werden, wenn es welche gibt. Wenn also alle 8 Felder den Wert 0 enthalten, wird die Prozedur nicht aufgerufen. Der User muß dann lediglich dran denken, die Nebenkosten im Rechnungskopf erst NACH der Erfassung der Positionen einzutragen.

Und siehe da: mit dieser Modifikation dauert es gerade mal noch 1 Minute anstatt über 1 Stunde, die 201 Positionen im RE zu erfassen.

Viele Grüße
Michael
Nur wer das Unmögliche versucht, wird das Machbare erreichen!
--
Datenbank: 2012-A02
Programm: 4.2.5.65
OS: Win 7 Pro / Ubuntu 10.04.3
Cyg
Beiträge: 45
Registriert: Mi Mai 31, 2006 2:37 pm

Beitrag von Cyg »

miboe hat geschrieben:Die Lösung ist erstaunlich einfach, auch wenn der User etwas mitdenken muß: Man setzt in BLRC_BU0 die Aufrufbedingung für P_BLRC_VERTEILEN so, daß auch wirklich nur dann Nebenkosten verteilt werden, wenn es welche gibt. Wenn also alle 8 Felder den Wert 0 enthalten, wird die Prozedur nicht aufgerufen. Der User muß dann lediglich dran denken, die Nebenkosten im Rechnungskopf erst NACH der Erfassung der Positionen einzutragen.

Und siehe da: mit dieser Modifikation dauert es gerade mal noch 1 Minute anstatt über 1 Stunde, die 201 Positionen im RE zu erfassen.

Viele Grüße
Michael
Hallo Micha!

Wir haben hier exakt das gleiche Problem. Wir sind noch in der Übergangsphase zu AvERP, deshalb wurden zwar alle Wareneingänge eingebucht, aber noch nicht die Rechnungseingänge.

Das Erfassen der Rechnungseingänge unseres Hauptlieferanten nach Wareneingang läuft nun schon seit 3 Tagen auf dem Server :evil:


Welche 8 Felder muß ich auf ungleich 0 testen? Oder besser noch: Schreib doch mal den geänderten Trigger hier rein.


Herzlichen Dank im voraus.
miboe
Beiträge: 1295
Registriert: Fr Jul 28, 2006 9:13 am

Beitrag von miboe »

Ich muß nachher auf meinem Laptop graben und poste dann hier ein Skript oder schicke es per PM. Finde ich im Profil denn eine Mailadresse, wo ich was hinmailen kann? Das Skript hat schon ein paar Zeilen ...

Gruß
Michael
Nur wer das Unmögliche versucht, wird das Machbare erreichen!
--
Datenbank: 2012-A02
Programm: 4.2.5.65
OS: Win 7 Pro / Ubuntu 10.04.3
Cyg
Beiträge: 45
Registriert: Mi Mai 31, 2006 2:37 pm

Beitrag von Cyg »

Hallo !

Im Profil nicht, aber ich schreib die adresse in ne PM
Antworten