New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Schlechte Performanz der 3er-Versionen #328
Comments
Danke für die Rückmeldung. Folgende Version wurde mit einem älteren Groovy-Compiler (V2.5.15) übersetzt. Bitte testen und berichten. 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 will be started in a docker container (based on jokay/docker-ccu-historian) with command Nachtrag: Ich habe keine Ahnung, weshalb ich meine Antwort in Englisch geschrieben habe. An dem Tag muss ich wirklich mies draufgewesen sein. 😏 |
|
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.
Meine Schlussfolgerungen:
|
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". 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. |
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. |
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). @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. |
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.
|
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. |
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...
Nachtrag: Mein Ubuntu-Linux-Server ist üppig mit CPU und Memory ausgestattet und hat nur SSDs als Festspeicher.
The text was updated successfully, but these errors were encountered: