Geschwindigkeit Buchungen MySQL

[larsm]

Hallo,

Server: Raspberry Pi v1, debian 7
Leitung: 100/5 - Internet - 100/5
Übertragung: mysql port durch ssh getunnelt
Client: Windows 8, 10

Das anklicken der Mitgliederliste mit 85 Mitgliedern dauert ca. 20 sek. Dabei gehen ca. 2000 TCP Pakete mit 200-800 byte hin und her (wireshark). Immer im Wechsel Frage und Antwort. Dabei ist nichts an Server und Client ausgelastet: CPU (~2%), RAM, Leitungsdurchsatz (~30 kbyte/sek).

Ich vermute, dass hier sehr ineffizient sehr viele SQL Abfragen gemacht werden. Bei einer Latenz von ca. 18ms dauert es dann nunmal so lange.

Bei anderen Listen läuft es nahezu Verzögerungsfrei: ganz Hibiscus, Buchungen in JVerein. Hier fließen weniger und größere Pakete.

JVerein muss im jedoch erheblich komplexere Abfragen haben, so dass es manchmal ewig dauert.

Auch komplexeste SQL Abfragen schicken die Antwort in einem Rutsch. Die Latenz bei sehr viele Abfragen ist das Problem.

Ist da eine Code Optimierung denkbar? Ich kann leider kein Java.

Gruß
Lars

[heiner]

Hallo Lars,

im Laufe der Entwicklung wurden immer mehr Tabellen an die Buchungen angeschlossen. Die Mimik, die Daten aus der Datenbank zu laden, wird von Jameica geliefert. Darauf habe ich keinen Zugriff. Mit der H2-DB funktioniert es bei mir problemlos.

Heiner

[larsm]

Nach ein Paar Monaten JVerein per Mysql nun meine Erfahrungen:

Die Auflistung der 90 Mitglieder dauert lokal im LAN unter 10s. Per SSH Tunnel über schnelles Internet dauert es ca. 20s.

Am Anfang ging die Arbeit mit Buchungen noch recht zügig. Nachdem wir allerdings die 1600 Buchungen kategorisiert und Mitgliedern zugeordnet hatten, dauer ein Aufruf der Liste über das Internet fast 3 min.

Der Flaschenhals scheint die Leitungslatenz zu sein. Es werden hunderte kleine Pakete hin und her geschickt. Die Bandbreite ist nicht annähernd ausgeschöpft.

Fazit: Mysql ist im LAN mühsam nutzbar, wenn man genug Gedult aufbringt geht es aber. Über das Internet ist es nicht nutzbar.

[heiner]

Das Problem stellt sich immer mit Applikationen, bei denen die Datenbank entfernt steht. Das ist kein spezielles Problem von JVerein.

Heiner

[ako]

Hallo Heiner,

Ich würde mir auch wünschen, wenn man sich dieses Themas annehmen würde.
Das erachte ich als ziemlich wichtig. Wenn man den Traffic anschaut, sieht man, dass wohl das Datenbank-Framework die SQL-Abfragen einzeln Datensatz für Datensatz losschickt, anstatt eine Abfrage für die gesamte Tabelle zu machen.
Ich würde auch was dafür spenden (da die Alternative aktuell ist, auf eine kommerzielle webbasierte Lösung umzusteigen).

Technisch geht das natürlich problemlos, man muss eine Liste so laden, dass man die Daten aus einer SQL-Anweisung holt, dann merkt man überhaupt keinen Performanceunterschied (bzw. nur die einmalige 20 Millisekunden Latenz bei der einen SQL-Anweisung oder meinetwegen noch 10x 20 Millisekunden, wenn man Daten von 10 Tabellen zieht und die nicht in einer Anweisung Joinen kann, aber eben nicht ein paar Tausend mal 20 Millisekunden Lazenz hintereinander).
Alle modernen Datenbankframeworks sollten das auch machen, da ferne Datenbanken in der Cloud seit einigen Jahren Standard ist. Einzelne SQL-Anweisungen rumzuschicken hat man meistens aus Frameworks die aus der Zeit 2000-2008 stammen (und wenn die weiterentwickelt werden, optimiert man die heute auch auf Cloud-Datenbanken).
Heute wird ja bald die Hälfte aller weltweiten Daten bei Amazon AWS, Microsoft Azure oder ähnlichen Cloudanbietern gehostet (natürlich hinter einem VPN bestmöglich geschützt).

Es wäre super, wenn das mit jVerein auch ginge. Unser Vereinsvorstand greift eben auch über VPN auf einen zentralen MySQL-Server zu und trotz 100 MBit-Internetanbindung zuhause und 1000 MBit Internetanbindung im Rechenzentrum ist es unerträglich langsam (eben die 20ms Latenz schlagen hier zu).

Viele Grüße,
Arnulf

[heiner]

Hallo Arnulf,

inzelne SQL-Anweisungen rumzuschicken hat man meistens aus Frameworks die aus der Zeit 2000-2008 stammen (und wenn die weiterentwickelt werden, optimiert man die heute auch auf Cloud-Datenbanken).

Genau das ist bei Jameica der Fall. Bitte wende ich an Olaf Willuhn im Homebanking-Forum. Wenn, dann kann der was daran ändern.

Heiner

[Boby]

Genau das ist bei Jameica der Fall. Bitte wende ich an Olaf Willuhn im Homebanking-Forum. Wenn, dann kann der was daran ändern.

Heiner

Hallo Heiner,
habe genau die Frage an Olaf gestellt - hier seine Antwort:

Wenn es zu Verzoegerungen beim Laden von Daten kommt, dann muss sich das jeweilige Plugin darum kuemmern. Solche Verzoegerungen koennen
entstehen, wenn entweder sehr viele Daten geladen und uebertragen werden. Oder wenn viele SQL-Abfragen durchgefuehrt werden. In Hibiscus
implementiere ich auch regelmaessig Optimierungen in der Richtung. Wenn in JVerein ebenfalls solche Verzoegerungen drin sind, dass muessen die
hierbei ausgefuehrten SQL-Abfragen analysiert und optimiert werden. Und wenn sich das nur mit Caching loesen laesst, dann muss das in dem Plugin implementiert werden, nicht in Jameica.

Gruss
Olaf

Ich bin mit meiner Instanz nun von meinem Webserver auf ein lokales NAS umgezogen, weil bestimmte Aktionen extrem lange gedauert haben (z.B. die Fehlbeträge der Mitglieder braucht 40-60 Sekunden - und das bei ca. 40 Mitgliedern).

Sonst liebe ich JVerein und finde die Funktionen toll und es kann alles was ich brauche (und noch mehr).

LG,
Boby

[hibiscus]

Alle modernen Datenbankframeworks sollten das auch machen, da ferne Datenbanken in der Cloud seit einigen Jahren Standard ist. Einzelne SQL-Anweisungen rumzuschicken hat man meistens aus Frameworks die aus der Zeit 2000-2008 stammen (und wenn die weiterentwickelt werden, optimiert man die heute auch auf Cloud-Datenbanken).

Hierzu müsste man entweder JVerein auf ein anderes Datenbank-Framework portieren (was technisch kein Problem wäre - Jameica schreibt nicht vor, dass man dessen Persistenz-Framework verwendet, kann genauso jedes Framework eigener Wahl verwenden) oder das in Jameica integrierte entsprechend erweitern. Keine von beiden Aufgaben ist eine technisch unlösbare aber beide erzeugen einen Aufwand, den weder Heiner noch ich mal eben so nebenbei erledigen können. Bedenke, dass wir die Software primär allein und in der Freizeit entwickeln.

Daher: Du kannst dich gern mit dem Thema beschäftigen, wenn du weiss, dass sowas heutzutage kein Problem mehr darstellt und nur noch in Frameworks aus 2000-2008 auftritt.Ich würde mich auch freuen, wenn das Datenbank-Framework mal aus der Computer-Steinzeit von 2000-2008 geholt werden könnte, in dem es sich wohl befindet. Also - nur zu. Bei Github kann man prima Pull-Requests einreichen.

Die Alternative ist, die ineffizienten Stellen im Programm ausfindig zu machen und entsprechende Caching-Machanismen einzubauen oder die SQL-Queries entsprechend umzubauen. In Hibiscus habe ich genau solche Änderungen Ende Dezember auch an einigen Stellen vorgenommen. Das war auch mit einer Arbeit verbunden.

Wie man es auch dreht, es ist kein triviales Problem, welches mal eben durch Ersetzen gegen eine "moderne" Bibliothek löst. Ich lasse mich aber gern vom Gegenteil überzeugen.