CAO - FAKTURA

Hallo,

ich versuche aktuell herauszufinden, warum die Kassenbuchungen mittlerweile (scheint ein schleichender Prozess zu sein, wir verwenden CAO auch schon seit mehr als 10 Jahren) quälend langsam sind.

Der Abschluss eines Bons mit einem auf Warengruppe gebuchten Artikel braucht aktuell 65(!) Sekunden. Daher habe ich mir mal das SQL-Log zwischen "F11" und "Schublade auf" angesehen.
Was mit erstaunt ist, dass dort der Eintrag "EDI-Mengen aktualisieren :35,23Sek." auftaucht. Das erscheint mir doch ein wenig lang.

Jemand eine Idee, wo man da ansetzen könnte?

Gruss

Macavity

Hallo,

Version 1.4.3.1?
Bevor hier jemand hilft, bitte zuerst CAO auf die aktuelle Version bringen: 1.4.4.208!

Hallo,

meinst Du das würde etwas ändern?
Wurde in der Kassensoftware was geändert?

Gruss

Macavity

Nein aber an der Datenbank.
Software auf dem aktuellsten Stand halten hilft oft

hh-cm hat geschrieben:Software auf dem aktuellsten Stand halten hilft oft

Nein, das kann nicht sein!

Also muss ich jetzt wirklich die DB aufräumen, da drück ich mich schon die ganze Zeit drum.
Redone sollte sich die DB noch erst ansehen (war mal vor gaaaaanz langer Zeit telefonisch besprochen worden).

Dann weiß ich ja, was an diesem Wochenende zu tun ist. Hauptsache meine anderen Programme die auf die CAO-DB (nur lesend) zugreifen funktionieren dann noch.

Gruss

Macavity

Ich hab vorhin mit Thoren darüber gesprochen.

Beim durchfliegen des Codes stellen sich mir folgende Fragen.

- Wieviele offenen (Vorgänge) Rechnungen gibt es in dem Mandanten ?
- Wieviele Zeilen gibt es in den Tabellen JOURNALPOS, LIEFERSCHEIN_POS und ARTIKEL_BDATEN ? (Mit Heidisql o.ä prüfen)
- Wieviel RAM hat der DB Server?

Bei wachsender Zahl der Belege wird es zwangsläufig langsamer, aber SO langsam auch nicht.
Optimieren, Reparieren der DB wurde bestimmt schon gemacht oder ?

Und vielleicht mal die MySQL Config Datei an dev(at)cao-faktura.de schicken.

Hauptsache meine anderen Programme die auf die CAO-DB (nur lesend) zugreifen funktionieren dann noch.

Feldnamen o.ä haben sich nicht geändert. Es sind halt nur Felder bzw. Tabellen hinzugekommen. Daher sollten eigentlich auch externe Scripte / Programme noch laufen.

Hallo Chris,

danke für deine Antwort.

Anzahl an Zeilen in den jeweiligen Datenbanktabellen:
JOURNALPOS = 599969
LIEFERSCHEIN_POS = 499351
ARTIKEL_BDATEN = 2598

Der Server hat 768MB RAM.

Die Tabellen habe ich schon öfters mit CAO-Admin optimiert und repariert.
Auch den Lösungsversuch von http://forum.cao-wawi.de/viewtopic.php?f=18&t=1696 hat leider keinen Erfolg gebracht.

Die MySQL_Config Daten muss ich mir nachher mal raussuchen und schicke diese dann gerne an die E-Mailadresse.
Wie ermittele ich am einfachsten die Anzahl der offenen Vorgänge?
Hilft es, wenn ich den Kassen SQL-Log der Buchung poste / per E-Mail sende?

Gruss

Macavity

Macavity hat geschrieben: Anzahl an Zeilen in den jeweiligen Datenbanktabellen:
JOURNALPOS = 599969
LIEFERSCHEIN_POS = 499351
ARTIKEL_BDATEN = 2598

Ok, das ist ordentlich aber erklärt keine Minute wartezeit.

Macavity hat geschrieben: Der Server hat 768MB RAM.

Das halte ich für zu wenig.
MySQL nutzt einen Cache/Buffer für Indexfelder. Wenn dort zu wenig RAM vorhanden ist, wird auf der Festplatte rumgerödelt. Das kann bei langsamer Platte und langsamem Speicher schon mal dauern.
Meiner Erfahrung nach sind 2GB für einen reinen MySQL Server ausreichend, wobei der MySQL Variable key_buffer_size ca. 500MB zugewiesen werden sollten. Sollte auf dem Server noch etwas anderes laufen, muss das dementsprechend angepasst werden.

Macavity hat geschrieben: 1) Die MySQL_Config Daten muss ich mir nachher mal raussuchen und schicke diese dann gerne an die E-Mailadresse.
2) Wie ermittele ich am einfachsten die Anzahl der offenen Vorgänge?
3) Hilft es, wenn ich den Kassen SQL-Log der Buchung poste / per E-Mail sende?

1) Das würde helfen
2) Einfach mal in die Vorgänge schauen und überschlagen. Auf +-10 kommts nicht an.
3) Ja, in dem fall schon. Ich kenn die Befehle aber die Ausführungszeiten bei dieser DB nicht.

scheint ein schleichender Prozess zu sein, wir verwenden CAO auch schon seit mehr als 10 Jahren

Läuft der Server schon genau so lange ?

hh-cm hat geschrieben: Läuft der Server schon genau so lange ?

Ja. Kein Witz!

Der Server macht sonst nichts anderes außer MySQL.
Das Drucken einer Bestellung (Lieferschein + Rechnung per Stapelbuchen) braucht im LAN 15 - 18 Sekunden (gerade mitgestoppt).

In "Rechnung bearbeiten" stehen aktuell 1100 Rechnungen.

Davon ist aber viel alter "Schrott", der ablaufbedingt entstanden ist.
Das ist auch der Bereich den ich "aufräumen" sollte, bevor ich die DB zu Redone schicken sollte.

Anbei das Log der Kassenbuchung:

Code: Alles auswählen

20.08.15 11:07:35:596
SQL:CONNECT cao14
RES:OK.

20.08.15 11:07:35:659
SQL:SHOW COLUMNS FROM JOURNAL
RES:OK.

20.08.15 11:07:35:706
SQL:SHOW INDEX FROM JOURNAL
RES:OK.

20.08.15 11:07:35:784
SQL:select * from JOURNAL 
where REC_ID =179963

RES:OK.

20.08.15 11:07:35:893
SQL:SHOW COLUMNS FROM REGISTRY
RES:OK.

20.08.15 11:07:35:940
SQL:SHOW INDEX FROM REGISTRY
RES:OK.

20.08.15 11:07:35:987
SQL:select VAL_INT as QUELLE, VAL_CHAR as FORMAT,
VAL_INT2 as NEXT_NUM, VAL_INT3 as MAXLEN, MAINKEY, NAME
from REGISTRY
where MAINKEY="MAIN\\NUMBERS"
and VAL_INT=22

RES:OK.

20.08.15 11:07:36:065
SQL:UPDATE REGISTRY SET VAL_INT2= 11628 WHERE MAINKEY='MAIN\\NUMBERS' AND NAME='VK-KASSE'
RES:OK.

20.08.15 11:07:36:128
SQL:UPDATE JOURNAL SET QUELLE= 3, VRENUM= '011627', STADIUM= 9 WHERE REC_ID=179963
RES:OK.

20.08.15 11:07:36:174
SQL:SHOW COLUMNS FROM JOURNALPOS
RES:OK.

20.08.15 11:07:36:253
SQL:SHOW INDEX FROM JOURNALPOS
RES:OK.

20.08.15 11:07:36:315
SQL:select * from JOURNALPOS
where JOURNAL_ID =179963
order by POSITION

RES:OK.

20.08.15 11:07:36:424
SQL:UPDATE JOURNALPOS SET QUELLE= 3, VRENUM= '011627' WHERE REC_ID=690766
RES:OK.

20.08.15 11:07:36:549
SQL:delete from ARTIKEL_BDATEN where QUELLE=13
RES:OK.

20.08.15 11:08:11:596
SQL:insert into ARTIKEL_BDATEN select JP.ARTIKEL_ID,JP.QUELLE,0,0,SUM(IF(ISNULL(LP.MENGE),JP.MENGE,JP.MENGE-LP.MENGE)) from JOURNALPOS JP left outer JOIN LIEFERSCHEIN_POS LP on LP.RECHPOS_ID=JP.REC_ID where JP.QUELLE=13 and JP.ARTIKELTYP IN ("N","S","L","K","X") and JP.ARTIKEL_ID>0 group by JP.ARTIKEL_ID, JP.QUELLE having SUM(IF(ISNULL(LP.MENGE),JP.MENGE,JP.MENGE-LP.MENGE))!=0
RES:OK.

20.08.15 11:08:11:674
EDI-Mengen aktualisieren :35,23Sek.

20.08.15 11:08:11:815
SQL:SHOW COLUMNS FROM JOURNALPOS
RES:OK.

20.08.15 11:08:11:924
SQL:SHOW INDEX FROM JOURNALPOS
RES:OK.

20.08.15 11:08:12:018
SQL:SHOW COLUMNS FROM JOURNALPOS_SERNUM
RES:OK.

20.08.15 11:08:12:128
SQL:SHOW INDEX FROM JOURNALPOS_SERNUM
RES:OK.

20.08.15 11:08:12:237
SQL:select JPS.QUELLE,JPS.JOURNAL_ID,JPS.JOURNALPOS_ID,JPS.ARTIKEL_ID,JPS.SNUM_ID from JOURNALPOS as JP, JOURNALPOS_SERNUM as JPS where JP.JOURNAL_ID=179963 and JP.SN_FLAG="Y" and JP.MENGE>0 and JP.ARTIKEL_ID=JPS.ARTIKEL_ID and JP.REC_ID=JPS.JOURNALPOS_ID and JP.JOURNAL_ID=JPS.JOURNAL_ID

RES:OK.

20.08.15 11:08:12:346
SQL:UPDATE JOURNALPOS_SERNUM SET QUELLE=3 where JOURNAL_ID=179963
RES:OK.

20.08.15 11:08:12:346
SQL:DISCONNECT cao14
RES:OK.

20.08.15 11:08:20:096
SQL:delete from JOURNAL_OP where QUELLE IN (3,4);

RES:OK.

20.08.15 11:08:33:409
SQL:insert into JOURNAL_OP select J.QUELLE,J.ADDR_ID,J.REC_ID,J.BSUMME,COUNT(ZA.REC_ID),IFNULL(SUM(ZA.BETRAG+ZA.SKONTO_BETRAG),0),J.WAEHRUNG from JOURNAL J left outer join ZAHLUNGEN ZA on ZA.JOURNAL_ID=J.REC_ID where J.QUELLE=3 and J.ADDR_ID>0 and YEAR(RDATUM)>2000 and J.STADIUM IN (2,3,4,5,6,7,11) group by J.REC_ID having IFNULL(SUM(ZA.BETRAG+ZA.SKONTO_BETRAG),0)<J.BSUMME

RES:OK.

20.08.15 11:08:33:690
SQL:insert into JOURNAL_OP select J.QUELLE,J.ADDR_ID,J.REC_ID,J.BSUMME,COUNT(ZA.REC_ID),IFNULL(SUM(ZA.BETRAG+ZA.SKONTO_BETRAG),0),J.WAEHRUNG from JOURNAL J left outer join ZAHLUNGEN ZA on ZA.JOURNAL_ID=J.REC_ID where J.QUELLE=4 and J.ADDR_ID>0 and YEAR(RDATUM)>2000 and J.STADIUM IN (2,3,4,5,6,7,11) group by J.REC_ID having IFNULL(SUM(ZA.BETRAG+ZA.SKONTO_BETRAG),0)>J.BSUMME

RES:OK.

20.08.15 11:08:38:237
SQL:select * 
from JOURNAL 
where QUELLE=13 and QUELLE_SUB=2 and TERM_ID=12
limit 0,1

RES:OK.

20.08.15 11:08:38:424
SQL:INSERT INTO JOURNAL (TERM_ID, QUELLE, REC_ID, QUELLE_SUB, ADDR_ID, ATRNUM, VRENUM, VLSNUM, FOLGENR, KM_STAND, KFZ_ID, VERTRETER_ID, GLOBRABATT, ADATUM, RDATUM, LDATUM, PR_EBENE, LIEFART, ZAHLART, KOST_NETTO, WERT_NETTO, LOHN, WARE, TKOST, MWST_0, MWST_1, MWST_2, MWST_3, NSUMME, NSUMME_0, NSUMME_1, NSUMME_2, NSUMME_3, MSUMME, MSUMME_0, MSUMME_1, MSUMME_2, MSUMME_3, BSUMME, BSUMME_0, BSUMME_1, BSUMME_2, BSUMME_3, ATSUMME, ATMSUMME, WAEHRUNG, GEGENKONTO, SOLL_STAGE, SOLL_SKONTO, SOLL_NTAGE, SOLL_RATEN, SOLL_RATBETR, SOLL_RATINTERVALL, STADIUM, ERSTELLT, ERST_NAME, KUN_NUM, KUN_ANREDE, KUN_NAME1, KUN_NAME2, KUN_NAME3, KUN_ABTEILUNG, KUN_STRASSE, KUN_LAND, KUN_PLZ, KUN_ORT, USR1, USR2, PROJEKT, ORGNUM, BEST_NAME, BEST_CODE, INFO, BEST_DATUM, FREIGABE1_FLAG, BRUTTO_FLAG, MWST_FREI_FLAG, PROVIS_WERT, MA_ID, ROHGEWINN, PRINT_FLAG, GEWICHT) VALUES (12, 13, NULL, 2, -2, '', '', '', -1, -1, -1, -1, 0, '1899-12-30', '2015-08-20 11:08:38', '1899-12-30', 5, 0, 1, 0, 0, 0, 0, 0, 0, 19, 7, 19, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, '', -1, 0, 0, 1, 1, 0, 0, 0, '2015-08-20', 'Kassenbenutzer', '', '', 'Barverkauf', '', '', '', '', '', '', '', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 'N', 'Y', 'N', 0, 2, 0, 'N', 0)
RES:OK.

20.08.15 11:08:38:503
SQL:SELECT LAST_INSERT_ID()
RES:OK.

20.08.15 11:08:38:706
SQL:select * 
from JOURNALPOS 
where TOP_POS_ID=-1 and JOURNAL_ID=179964

RES:OK.

Macavity hat geschrieben: Ja. Kein Witz!

Hat der schonmal eine neue Festplatte gesehen ?

Macavity hat geschrieben: Der Server macht sonst nichts anderes außer MySQL.
Das Drucken einer Bestellung (Lieferschein + Rechnung per Stapelbuchen) braucht im LAN 15 - 18 Sekunden (gerade mitgestoppt).

Brrr. Stop. Zu lange.

Macavity hat geschrieben: In "Rechnung bearbeiten" stehen aktuell 1100 Rechnungen.
Davon ist aber viel alter "Schrott", der ablaufbedingt entstanden ist.
Das ist auch der Bereich den ich "aufräumen" sollte, bevor ich die DB zu Redone schicken sollte.

Sollte ?

Zusammenfassung.
- Stetig wachsende anzahl an Belegen
- Gleichbleibende Hardware (RAM etc.)
- ^--- ALTE HARDWARE
- "Schrott" in der DB

Langsam verstehe ich die eingangsfrage nicht mehr

ALT ist nicht gleich SCHLECHT. Soviel steht fest.
Bei einem 10 Jahre alten Server mit 768MB Ram (Kann man sowas noch kaufen?) sehe ich das wohl anders.

Langsam ist mal ein Upgrade angesagt.
Gibts keinen ausgedienten PC (MIN. 2 Kerne mit min. 2GB Ram) ?
Neue Platte rein, Linux drauf - nächsten Jahre ruhe.

Macavity hat geschrieben: Anbei das Log der Kassenbuchung:

Anhand der neuen Erkenntnisse erst mal egal

hh-cm hat geschrieben: Hat der schonmal eine neue Festplatte gesehen ?

Nein, wozu?

Neuer Server steht daneben. 12GB RAM + Quad-Core.

Ich werde also erstmal den alten Schrott in "Rechnung bearbeiten" entsorgen und den MySQL-Server umziehen.

Gruss

Macavity

CAO - FAKTURA

Kassenbuchungen sehr langsam

Kassenbuchungen sehr langsam

Re: Kassenbuchungen sehr langsam

Re: Kassenbuchungen sehr langsam

Re: Kassenbuchungen sehr langsam

Re: Kassenbuchungen sehr langsam

Re: Kassenbuchungen sehr langsam

Re: Kassenbuchungen sehr langsam

Re: Kassenbuchungen sehr langsam

Re: Kassenbuchungen sehr langsam

Re: Kassenbuchungen sehr langsam

Re: Kassenbuchungen sehr langsam