CubeSQL langsamer Import
Hallo,
wie kommt es, dass die Arbeit auf CubeSQL so langsam ist?
Insbesondere beim Datenimport von Textdateien kann man sagen, 1 Buchung pro 30 bis 60 Sekunden,
---
Am Server wird es nicht liegen (MacMini I7 mit 16GB Ram und SSD)
Ich kann mir im Prinzip nur vorstellen, dass vor jeder Buchung ein neuer Connect zur Datenbank aufgebaut wird und nach dem Import jeder Zeile wieder disconnected wird.
Bin sehr auf Antworten gespannt.
Gruß
Christian
-
Die Frage ist zwar schon etwas älter, aber ich muss hier nochmals nachhaken:
Bei einem Kunden (Treuhänder) von mir läuft cubeSQL auf einem Synology NAS. Normale Buchungen funktionieren recht gut. Wenn es aber um einen Import geht, ist das System wie schon oben abgesprochen extreeeeeem langsam!! Ein Import, welcher lokal innert wenigen Sekunden erledigt ist, braucht über die Serververbindung Stunden. Absolut unbrauchbar!
Getestet haben wir es auf zwei NAS (DS918+/DS920+/DMS7) in zwei verschiedenen Netzwerken (einmal beim Kunden, einmal bei mir). Ebenfalls getestet wurde mit der cubeSQL App und mit einer Docker-Installation (cubeSQL Server 5.9.1). Die Clients sind über Ethernet verbunden.
Gibt es irgendwelche Einstellungen oder sonst einen Trick den man kennen muss? Gibt es sonst jemand, der dieses Problem bestätigen kann oder bei dem es wirklich brauchbar schnell läuft? Wie gesagt: Es betrifft nur normale Text-Imports (egal ob Lohn- oder Fibu-Buchungen).
Gruss Dave
-
Neue Erkenntnis nach weiteren Tests:
Offenbar hat der langsame Import nichts mit der Synology oder dem Netzwerk zu tun. Wie im Originalbeitrag beschrieben ist es auch auf einem Mac mini schon passiert und gestern wurde es auch auf einem Ubuntu System getestet. Überall das gleiche Problem! (Ohne dass die entsprechenden Server auch nur annähernd ausgelastet wären.)Das lässt eigentlich nur noch zwei Möglichkeiten offen:
1.) Monkey Office ist über das Netzwerk langsam.
2.) cubeSQL ist der Flaschenhals.Da das Problem schon seit Jahren auftritt, würde ich mal die Versionen (Monkey/cubeSQL) ausschliessen. Ich kann mir aber sehr gut vorstellen, dass das Problem einfach bisher nicht richtig wahrgenommen wurde. Erstens weil es bei kleinen Imports mit wenigen Datensätzen nicht wirklich ins Gewicht fällt und vielleicht nur wenige Leute überhaupt hunderte oder tausende von Datensätzen importieren. Und zweitens, weil evt. gar nicht so viele Leute mit einem cubeSQL Server arbeiten. Lokal ist der Import ja kein Problem.
Huston, we have a problem!
-
Leider wird das Problem wohl weiterhin nicht erkannt. Zumindest herrscht hier eisernes Schweigen.
Ich hab hier ein MacBook Pro mit M1 Max, 64 GB RAM und Gigabit Ethernet. Der Server auf der Gegenseite hängt am selben Switch, ebenfalls Gigabit Ethernet und dreht Däumchen. RAM-Auslastung bei 10%, CPU bei 5%. Mit MO arbeiten fühlt sich trotzdem an, wie durch Leim zu waten. Und Gnade Gott du versuchst, MO per VPN zu nutzen. In Zeiten mit Home Office passt diese Lösung einfach nicht mehr.
CubeSQL macht den Eindruck als würde es von einem 1-Mann-Unternehmen betrieben. Keine Support-Seiten, nur ein Blog mit Release-Notes, keine Infos zu den System Requirements.
Ich will ja nicht ausschließen, dass das Problem noch irgendwo bei uns im Netzwerk liegt, aber alle anderen Dienste auf dem Server performen und im Netz finde ich auch keine Infos dazu, was ich tun könnte.
Und dabei haben wir über das Problem, das ich hier bereits 2021 angemerkt habe, noch nicht mal geredet: Die riesige Datenbank. Wir sind ein Minibetrieb mit ein paar hundert Belegen im Jahr. Unsere DB hat 400 MB und wird auch nicht kleiner, wenn ich Anlagen und Mails rauslösche (vorher natürlich extern archiviert). Dazu muss ich sie erst runterladen und neu zurückladen. Die Reorganisation, die den Job eigentlich machen sollte, macht in dieser Hinsicht gar nichts.
Komprimieren kann man die Backups auch nicht, weil verschlüsselt. Die werden dabei eher noch größer. Heißt: Wir jagen jede Nacht zweimal 400 MB durch die Gegend für Offsite-Backups und bezahlen natürlich auch den Speicherplatz dafür. Klar stirbt davon niemand. Aber es ist brutal nervig, erst recht wenn ich sehe, wie smooth wir jede Nacht ein paar hundert Wordpress-Websites wegsichern (wir machen auch Webhosting).
-
@Tim Kaufmann: Also bei meinem Kunden haben wir die CubeSQL Installation vom Synology NAS wieder auf einen mac Mini (M2) zurückgewechselt. Seitdem kann er wieder arbeiten... Aber ja, das Problem hast du gut beschrieben. Das System ist einfach nicht professionell auf dieser Grundlage.
-
@Tim Kaufmann: Die Idee hinter CubeSQL ist ja, dass die Datenbank auf einem anderen Gerät (Server) läuft als die Monkey Office App. So dass mehrere Personen gleichzeitig darauf zugreifen können. Wenn man Monkey Office nur auf einem Arbeitsplatz einsetzt, braucht es sein CubeSQL, da man ja rein lokal arbeitet.
Bei meinem Kunden war anfangs vor allem der Import eine extrem langsame Sache. Allerdings hat er sich dann mit der Zeit auch beklagt, dass die einzelnen Buchungen übermässig viel Zeit benötigen, darum haben wir dort wieder einen Wechsel zurück zu einem (neuen) Mac mini als Server gemacht.
Ich frage mich effektiv, ob CubeSQL die richtige DB für MO ist oder ob sich eine andere DB nicht besser eignen würde...? Aber das liegt natürlich in der Entscheidung der Entwickler. -
Dave Camenisch Ja, das liegt auf der Hand, aber bevor man aneinander vorbeiredet …
Wenn das, was ich mir über CubeSQL zusammenreime, stimmt, dann kann das nicht ideal sein. Im Hintergrund bleibt es bei einer SQLite-Datei, über die CubeSQL einfach eine Netzwerkschicht legt. Die Datei hat 400 MB. Für's Lesen kann CubeSQL die Datei im RAM cachen. Aber beim Schreiben ist das mit dem Caching nicht so leicht. Geht zwar, verursacht aber Folgeprobleme (Inkonsistenzen bei Stromausfall, Abstimmung paralleler Zugriffe usw.).
Letztlich hat das CubeSQL vor allem für die MO-Entwickler den Vorteil gehabt, dass sie die bestehende SQLite-Struktur, die für Einzelplatz sicherlich ihre Vorteile hatte, beibehalten konnten, als es ins Netzwerk ging.
Der Support von CubeSQL hat sich noch nicht gemeldet, aber es war ja auch Weihnachten. ich hak' da mal nach.
-
Gibt es hier inzwischen neue Erkenntnisse?
Wir setzen MonKey Office in unserem Unternehmen ebenfalls auf M1-Macs ein, der CubeSQL (schreckliches Produkt!) -Server liegt auf einem enorm leistungsstarken Server als VM.
Dass man sich in MO wie durch Melasse bewegt, kann ich nur bestätigen.
Die Endgeräte „langweilen“ sich, der Server idlet vor sich hin und das 10 Gigabit-Netzwerk langweilt sich. Aber jeder Klick, jede Datumsänderung im Filter, eigentlich alles Scheint eine DB-Abfrage zu starten die viele Sekunden benötigt, bis sie abgeschlossen ist.
Eine Änderung an Bankauszügen dauert Minuten!
Die Arbeit über das VPN ist fast unmöglich. Die Firma ist mit mehreren Gigabit über das Internet angebunden, die Mitarbeiter haben mind. 500 MBit/s-Anbindungen daheim.
Der CubeSQL-Support meldet sich nie auf eine Anfrage (natürlich auf Englisch, da die Firma ja in Italien sitzt).
Kann man von Seiten ProSaldo nicht mal auf eine Open Source-Lösung (z. B. PostgreSQL) setzen? Dann erübrigen sich auch die teuren Lizenzen … -
Ich bin mittlerweile soweit, dass ich recht sicher ausschließen kann, dass es an CubeSQL liegt.
Die Kollegin mit dem Windows-Computer kann ziemlich normal arbeiten.
Wenn ich Monkey Office Connect (den API-Server) auf meinem Mac laufen lasse und mit PHP darauf zugreife läuft das superschnell.
Nur in der Desktop-Anwendung Monkey auf dem Mac ist es unerträglich langsam.
Leider interessiert das Thema hier niemanden, zumindest nicht so dass es nach außen erkennbar wäre. Monkey Office wird zwar als Lösung für Windows und Mac vermarktet (und wurde deshalb auch von uns gekauft), aber über die Jahre ist es auf dem Mac immer langsamer geworden. Und mittlerweile ist es echt so, dass ich damit nicht ernsthaft arbeiten wollen würde, sondern nur nachschlage und hier und da mal eine Rechnung schreibe.
-
Ah, okay – danke für die Einschätzung!
Habt ihr euch diesbezüglich schon direkt an den ProSaldo-Support gewandt? Also nicht nur über die Community-Seite? So wie Du das Problem beschreibst, scheint es ja ein Applikationsproblem zu sein.
Wir nutzen ausschließlich Mac-Endgeräte. Ich sollte dennoch zum Vergleich mal einen Windows-Client versuchen. Doch gerade weil MO seinerzeit die einzig solide Mac-Buchhaltungssoftware war, haben wir uns dafür entschieden.
So bringt es leider wirklich keine Freude, das Programm zu nutzen. I. d. R. schaut man dem Beachball of Death beim Drehen zu … -
Hi,
nein, hab ich nicht. Eigentlich gehe ich schon davon aus, dass der Hersteller hier mitliest, bei anderen Themen klinkt er sich ja auch ein. Aber vielleicht wäre das etwas, das du übernehmen würdest?
Ich weiß ehrlich gesagt nicht, was ich von MO/ProSaldo halten soll. Auf der einen Seite weiß ich es zu schätzen, dass man auch auf Sonderthemen wie "Wir machen mal ein halbes Jahr 16% Mehrwertsteuer" reagiert. Andererseits gibt es so viele Kleinigkeiten in der Software, bei der ich mich frage, ob es eigentlich niemanden gibt, der das UX kontrolliert? Da ist die Geschwindigkeit der Applikation unter macOS nur eines von vielen Themen.
Nur die Beispiele, die mir wirklich ohne langes Nachdenken einfallen:
1. Markiere mal mehrere Positionen in einem Beleg und klick auf "-". Man erwartet, dass alle Positionen gelöscht werden - das geht aber nicht. Man muss einzeln markieren und klicken.
2. Markiere eine Position und drücke ⌘ + D, das ist am Mac ja Standard zum Duplizieren. GEht nicht.
3. Eine der am häufigsten aufgerufenen Funktionen, die PDF-Ausgabe, ist in der aktuellen Version in ein Dropdown gewandert? Für jeden Versand ein Extraklick. Eigentlich will man einen "E-Mail-"-Knopf in der Menüleiste, der auch die Auswahl des Templates überspringt.
4. Riesige Backups, die immer größer werden, weil alle Belege mitgespeichert werden, statt nur die relevanten Daten zu snapshotten, damit man die Belege bei Bedarf neu erzeugen kann. Das haben wir mal wo anders diskutiert, aber vorwärts geht es da auch nicht. Muss man von Hand ausdünnen.
Da haben wir noch nicht über Verbesserungsmöglichkeiten gesprochen, zum Beispiel einen "auf heutiges Datum setzen"-Knopf hinter dem Rechnungsdatum oder eine OpenAPI-kompatible API-Dokumentation, damit man sich selbst vernünftige Clients in der Programmiersprache der Wahl generieren kann.
Ja, ist der falsche Thread hier, aber irgendwo musste ich da gerade mal mit hin.
Also, wäre cool wenn du mal jemanden mit der Nase auf den Thread stoßen würdest. Die Anwendung lief auf macOS früher (wir sind seit ~10 Jahren dabei) besser, sonst hätten wir sie nicht angeschafft.
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
13 Kommentare