ccu-historian
ccu-historian copied to clipboard
mdzio
Schlechte Performanz der 3er-Versionen
Bisher lief bei mir V2.5.2. Also war es an der Zeit auf eine neue Version zu wechseln. Umzug auf einen neuen schnelleren Server und Update auf V2.8.3 war unkritisch - alles lief wie gewohnt. Dann habe ich V3.0.0-beta.3 getestet und die Migration nach Anleitung mit Export (createscript) und Import (runscript) durchgeführt. Hat eigentlich auch funktioniert, lediglich die Performance bei Zugriff auf die Webseite ist so schlecht, dass ich die 3er-Version noch nicht produktiv nutzen kann und Ja, ich kenne die Bedeutung von "beta". Bitte diese Meldung als Feedback betrachten.
Aus meiner Datenbankerfahrung vermute ich, dass in der Datenbank ein paar Indextabellen fehlen, die den Zugriff beschleunigen könnten. Dafür sprechen möglicherweise auch die Datenbankgrößen: 2er Version belegt über 5 GB, 3.0.0-beta3 nur noch 4.1 GB (Nein, ich habe vor dem Export keine Datenpunkte gelöscht, zumindest nicht dass ich mich erinnern würde).
Zahlen und Fakten bei 1200 Datenpunkten und 109,5 Millionen Datensätzen: Download Startseite 'http://localhost:8081/historian/index.gy' liefert jeweils 663kByte und benötigt beim ersten Aufruf nach dem Start des Historian...
- mit 2er-Version ca. 2,8 bis 3,1 Sekunden bei 340 bis 535 kbyte/sec; erneuter Aufruf unmittelbar nach dem ersten ist doppelt so schnell
- mit 3er-Version ca. 160 Sekunden bei nur 4,5 kbyte/sec; erneuter Aufruf unmittelbar nach dem ersten ist nur ca. 8% schneller. Mit anderen Worten: die 2er-Version ist auf meinem System um mindestens Faktor 80 schneller als die 3er.
Nachtrag: Mein Ubuntu-Linux-Server ist üppig mit CPU und Memory ausgestattet und hat nur SSDs als Festspeicher.
Danke für die Rückmeldung.
Folgende Version wurde mit einem älteren Groovy-Compiler (V2.5.15) übersetzt. Bitte testen und berichten. Funktional handelt es sich um die V3.0.0-beta.3.
Editiert: Download wurde entfernt, da noch ein Fehler entdeckt worden ist.
I have tried to use ccu-historian-3.0.0-beta.4-bin.zip with no success.
It fails to launch with the error message:
Error: Could not find or load main class mdz.ccuhistorian.Main
It will be started in a docker container (based on jokay/docker-ccu-historian) with command
java -Xmx1024m -Duser.timezone=Europe/Berlin -jar /opt/ccu-historian/ccu-historian.jar -config /opt/ccu-historian/config/ccu-historian.config
The very same container setup is okay with 3.0.0-beta.3 (slow but working).
Java is
openjdk version "1.8.0_312".
Nachtrag: Ich habe keine Ahnung, weshalb ich meine Antwort in Englisch geschrieben habe. An dem Tag muss ich wirklich mies draufgewesen sein. :smirk:
- Versuch: Folgende Version wurde mit einem älteren Groovy-Compiler (V2.5.15) übersetzt. Bitte testen und berichten. Funktional handelt es sich um die V3.0.0-beta.3. Sie ist nur mit Java 8 getestet. Java 16 funktioniert beispielsweise nicht.
ccu-historian-3.0.0-beta.4-bin.zip
ccu-historian-addon-3.0.0-beta.4.tar.gz
Die Software "ccu-historian-3.0.0-beta.4-bin.zip" (Versuch 2) habe ich getestet. Der Start der Anwendung funktioniert wieder. Es zeigt sich jedoch leider nur eine minimale Performanzverbesserung beim Seitenaufbau der Startseite mit allen Datenpunkten. Die Ladezeit liegt bei 148 Sekunden statt 160 Sekunden der beta3. Eine so geringe Verbesserung (~ 8%) kann auch von anderen äußeren Einflüssen auf meinem Server kommen oder eine Streuung von wiederholten Messungen.
Ich habe mir die CPU-Nutzung während der Datenübertragung angesehen. Die Performanzproblematik der 3er-Version scheint nicht an einer erhöhten CPU-Last zu liegen.
Daher habe ich mit tcpdump den Netzwerkverkehr betrachtet. Auf dem Netzwerk habe ich folgendes feststellen können:
- Die Versionen 3.0.0-beta.4 und 2.8.3 übertragen beide im Schnitt 9 bis 10 kleine Netzwerkpaketen pro Datenpunkt mit einer durchschnittlichen Größe von 62 bis 65 Byte (payload data).
- Der Client schickt an den 2.8.3er-Server im Schnitt nach jedem achten Paket ein ACK zurück. Bei der 3er-Version wird schon nach jedem zweiten Paket ein ACK zurückgesendet. Ich gehe davon aus, dass der Server auf alle ACKs wartet bevor er neue Pakete verschickt. Das kostet Zeit.
Meine Schlussfolgerungen:
- zu 2: Es scheint mir, dass der Server auf diese ACK-Pakete wartet bevor er die nächsten Pakete verschickt. Daraus schließe ich, dass sich die Konfiguration oder Nutzung der TCP-Netzwerkverbindung zwischen den genannten Versionen unterscheiden muss. Am Docker-Container liegt es nicht. Der ist bei beiden Instanzen identisch. Also hat sich das Verhalten der Historian-Software bzw. der Java-Laufzeitumgebung verändert.
- zu 1: Generell ist die Übertragung von kleinen Datenpaketen schlecht für die Performanz. Die Anzahl der übertragenen Einzelpakete sollte sich durch eine Konfigurationsänderung im Historian leicht von 9 bis 10 Paketen pro Datenpunkt auf 1 Paket für 2 Datenpunkte (Faktor 20) reduzieren lassen. Für die Performanz wäre es wünschenswert wenn der Historian die maximal mögliche Netzwerkpaketgröße auszunutzen würde (ca. 1460 Bytes).
- Der jeweils verwendete Groovy-Compiler scheint keinen Einfluss zu haben.
Danke für die ausführliche Analyse. Dann werde ich mal bei der Konfiguration des eingebetteten Web-Servers weiter schauen.
Eventuell hilft Dir bei der Analyse das Stichwort "Nagle-Algorithmus".
Der deutsche Wikipedia-Artikel ist sehr kurz. Der englische "Nagle's algorithm" ist detaillierter.
Mit dieser TCP-Socket-Option werden die Pakete nicht größer, aber es werden mehrere Pakete hintereinander verschickt bevor der Server auf ein ACK wartet. Damit hat man das Verhalten mit dem Verschicken viele kleiner Pakete zwar nicht geändert, aber die Netzwerk-Latenz wird verringert.
Ich vermute dass damit eine Beschleunigung von Faktor 8 möglich ist. Wenn dieser Faktor nicht deutlich höher ausfallen sollte, dann bedeutet das dass das Netzwerkverhalten nicht alleine für die von mir beobachtete schlechte Performanz (Verschlechterung um Faktor 80) schuld sein kann.
- Versuch: Folgende Version wurde mit einem älteren Groovy-Compiler (V2.5.15) übersetzt. Bitte testen und berichten. Funktional handelt es sich um die V3.0.0-beta.3. Sie ist nur mit Java 8 getestet. Java 16 funktioniert beispielsweise nicht.
Hi, gibt es auch ein Paket für Synology NAS zum testen?
Generell werde ich wieder den Compiler in der Version 2.5 verwenden, da damit ein Fehler auf dem Tinkerboard S behoben wird. Dann wird es auch wieder Versionen für Synology geben.
Mit dem Release von V3.0.0 und dem neuen eingebettetem Webserver bleibt die Performanz weiterhin schlecht. Die Startseite lädt nur mit ~ 4,5KB/s. Bei 1200 Datenpunkten dauert das 2,5 Minuten.
Leider besitzt der eingebettete Web-Server Jetty keine Einstellmöglichkeiten auf so niedriger Netzwerkebene. Die Ursache des Unterschieds zwischen V2.8.3 und V3 ist für mich weiterhin unklar.
Ich habe nochmal über das Problem nachgedacht und bin zu der neuen Schlussfolgerung gekommen, dass meine frühere Schlussfolgerung nicht alle Möglichkeiten betrachtet hat. Wir sind bisher davon ausgegangen, dass die Ursache der schlechten Performanz an der Netzwerkkonfiguration auf den unteren Ebenen des Webserver liegen müsse.
Aus anderen Programmiersprachen (z.B. perl) kenne ich folgendes: Einzelne Zeichen oder Worte mit "print" ausgegeben, werden gesammelt bis eine ganze Zeile mit "\n" (Newline) abgeschlossen wird. Erst dann übergibt der Interpreter die gesammelte Zeile in einem Systemaufruf an das OS (oder Netzwerk). Übertragen auf den ccu-historian könnte das bedeuten, dass version 2.x nur selten Newlines im html-output verwendet, die version 3.x dagegen viel häufiger oder dass V3 mehr einzelne Funktionsaufrufe verwendet als V2. Das könnte dazu führen, dass der Webserver die Daten in kleineren Häppchen übergeben bekommt und diese alle in einzelnen und viel kleinere Netzwerkpaketen verschickt.
@mdzio : Bitte prüfe mal Deinen Code zur Ausgabe eines einzelnen Datenpunkts ob es markante Unterschiede gibt zwischen V2 und V3 gibt.
Hinweis: Ich habe seit April keine neueren 3er-Versionen mehr getestet.
Die Anzahl der ausgegebenen "\n" hat sich eigentlich nicht geändert, und der Web-Server sollte die Ausgabe auch puffern, um größere Pakete zu schicken. Aber der Web-Server und die Programmiersprache Groovy, in der die Web-Seiten geschrieben worden sind, sind alles Komponenten, die im CCU-Historian eingebettet sind, und auf die ich keinen Einfluss habe. Hast Du mal andere Web-Browser ausprobiert oder ein aktuelleres Java-JRE?
Das gleiche Performance Problem mit der 3er-Version sehe ich bei mir ebenfalls (aktuell mit 3.3.0). Mit den 2er Versionen trat dieses Problem bisher nicht auf. In meinem Fall läuft der Historian auf einem Raspberry 4 (openjdk version "1.8.0_312"). Ein Aufruf der Webseite ist nahezu unmöglich, sobald der ccu-historian für ein paar Stunden lief.
- Nach einem Neustart des ccu-historian ist das Problem zuerst nicht vorhanden. Alles lädt relativ normal schnell. Über Zeit wird es dann jedoch immer langsamer, als wenn sich immer mehr Anfragen/Verbindungen ansammeln und nicht bedient oder geschlossen werden
- Daten seitens der CCU laufen ohne Probleme durchgehend ein auch wenn der Hänger Auftritt
- Versucht man den Prozess auf dem Raspberry zu beenden während obiger Hänger auftritt so reagiert dieser ebenfalls nicht auf einen Abbruch mittels kill (nur ein kill -9 schafft abhilfe).
Mit V3.5.0-beta.1 wird wieder der eingebettete Web-Server und der Compiler aktualisiert (siehe auch #399). Mehr Möglichkeiteiten gibt es leider nicht um das Problem bei Euch zu lösen. Deshalb schließe diesen Eintrag mal.