UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[TIPP] Grafana - Single Stat Abfragen beschleunigen

Diskussionen über Zeitserien, Logging und Auswertung mit Grafana
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS, CometVisu, Grafana, Edomi oder eine andere Software beteiligt ist, dann auch immer deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln

Ersteller
cheater
Reactions:
Beiträge: 610
Registriert: Sa Aug 11, 2018 11:16 pm
Hat sich bedankt: 381 Mal
Danksagung erhalten: 274 Mal

Grafana - Single Stat Abfragen beschleunigen

#1

Beitrag von cheater »

Ich habe in Grafana oft Dashboards, auf denen Single Stat Anzeigen und Graphen gemischt sind. Wenn man sich nun einen längeren Zeitraum anzeigen lässt, dann werden auch für die Single Stat Anzeigen jede Menge Werte abgerufen, obowhl ich mir eigentlich immer nur den letzten Wert anzeigen lasse. Nun habe ich nach einer Möglichleit gesucht die Single Stat Anzeigen zu tunen, um die Abfragen nicht unnötig zu verlangsamen.

Irendwo hier stand, das man mit dem Query Insepctor sehen kann, wie viele Werte aus der Datenbank abgerufen werden, das kann man hiemit gut nachprüfen.

Ich denke, die Lösung ist bei Select "last()" einzutragen. Hat man dies eingetragen wird nur noch ein Wert abgerufen. Kann mir das Jemand bitte bestätigen?
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Grüße, Dominic

Timberwolf 2400 #126, VPN offen, Reboot nach Absprache

BugRoger
Reactions:
Beiträge: 19
Registriert: Mi Okt 16, 2019 9:37 pm
Wohnort: Berlin
Hat sich bedankt: 12 Mal
Danksagung erhalten: 38 Mal

#2

Beitrag von BugRoger »

Ja, das ist subjektiv etwas schneller. Im Query Inspector werden jedenfalls weniger Objekte zurückgegeben.
Viele Grüsse, Michael

TWS 950 ID:470 + PBM ID:949, VPN offen, Reboot erlaubt

Robosoc
Reactions:
Beiträge: 1876
Registriert: Di Okt 09, 2018 9:26 am
Hat sich bedankt: 635 Mal
Danksagung erhalten: 775 Mal

#3

Beitrag von Robosoc »

cheater hat geschrieben: Di Jan 28, 2020 10:00 am Irgendwo hier stand, das man mit dem Query Insepctor sehen kann, wie viele Werte aus der Datenbank abgerufen werden, das kann man hiemit gut nachprüfen.
Das geht meines Wissens erst ab dem noch recht jungen Grafana V7.0 und daher aktuell (TWS V1.6) noch nicht in dem vorinstallierten Grafana, denn da ist (zumindest bei mir auf dem 950Q) V6.4.7 im Einsatz.

Aber die Fragestellung find ich sehr interessant. Ich schau mir das später auch mal an, ob über die Funktion "Last" hinaus noch weiter Dinge wirken (MinInterval, andere GroupBy Einstellungen, etc) und ob Last wirklich wirkt. Eventuell kann man irgendwo im Inspector auch die tatsächlich Ladezeiten einsehen.
VG, Sven - TWS 950Q ID:335 & 291, VPN offen, Reboot OK

Robosoc
Reactions:
Beiträge: 1876
Registriert: Di Okt 09, 2018 9:26 am
Hat sich bedankt: 635 Mal
Danksagung erhalten: 775 Mal

#4

Beitrag von Robosoc »

In Grafana 7.x (zusätzlich und experimentell installierte Container Lösung) sieht man im Inspect Modus die Gesamt-Query-Abfrage Zeit in s und die processing time in ms.

Ich teste aktuell mit einem Panel, in dem ich 5 GA's aus dem KNX-Logging auswerte, die täglich 1 oder 2 Mal gesendet werden, die zudem mit der Influx-Funktion Spread verdichtet werden und dann in eine 6-te Kurve mit dem Plugin MetaQuery aus den 5 anderen Balken mathematisch berechne.(4 Subtraktionen).
Dabei betrachte ich den gesamten Jahreszeitverlauf 2020 (also über den TimePicker von Grafana eingestellt)

Ohne setzen eines MinInterval zeigt mir der Query Inspektor folgende Angaben an:
Total request time 1,741 s
Data processing time 2 ms
Number of queries 6
Total number rows 1725

...


Sorry...jetzt, wo es spannend wird, kann ich arbeitstechnisch erstmal nicht weitermachen und melde mich später noch mal mit Vergleichenden Informationen .
Zuletzt geändert von Robosoc am Mi Jan 13, 2021 10:08 am, insgesamt 1-mal geändert.
VG, Sven - TWS 950Q ID:335 & 291, VPN offen, Reboot OK

Ersteller
cheater
Reactions:
Beiträge: 610
Registriert: Sa Aug 11, 2018 11:16 pm
Hat sich bedankt: 381 Mal
Danksagung erhalten: 274 Mal

#5

Beitrag von cheater »

Im Query Inspector sieht man auch jetzt (6.4.7) schon wie viele Arrays abgefragt wurden.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von cheater am Mi Jan 13, 2021 10:06 am, insgesamt 1-mal geändert.
Grüße, Dominic

Timberwolf 2400 #126, VPN offen, Reboot nach Absprache

Robosoc
Reactions:
Beiträge: 1876
Registriert: Di Okt 09, 2018 9:26 am
Hat sich bedankt: 635 Mal
Danksagung erhalten: 775 Mal

#6

Beitrag von Robosoc »

So ich mach mal weiter, wo och in Beitrag 4 aufgehört habe...

Der Wert weicht vom Post vorhin ab, weil es sicher abhängig davon ist, wie beschäftigt Grafana gerade ist und wie hoch die Speicherauslastung bzw. CPu ansonsten ist. Daher lohnt es sich nur die folgenden Angaben zu vergleichen, die alle beim gleichzeitigen Ladevorgang der Seite entstanden sind:

Ohne MinInterval-Vorgabe (wird von Grafana, vermutlich aufgrund der Auflösung des Bildschirms auf 6h gesetzt)
Total request time 2.703 s
Data processing time 1 ms
Number of queries 6
Total number rows 3396

Mit manuellem MinInterval = 1d
Total request time 2.478 s
Data processing time 2 ms
Number of queries 6
Total number rows 1725

Mit manuellem MinInterval = 1w
Total request time 2.745 s
Data processing time -1 ms
Number of queries 6
Total number rows 263

Mit manuellem MinInterval = 1M
Total request time 2.915 s
Data processing time -1 ms
Number of queries 6
Total number rows 65

Mit X-Achs Mode = Series on Total (statt time), und einer zusätzlichen Meta-Query-Addition, sowie 2 MetaQuery Groupierungen
Total request time 2.923 s
Data processing time -1 ms
Number of queries 9
Total number rows 8

Dieser Ergebnisse hatte ich so zunächst nicht erwartet. Ich hätte gedacht, dass das Ergebnis weniger Ladezeit bei weniger Balken bringt...ABER da habe ich nicht an die eigentliche Funktion von Spread gedacht, Spread vergleicht immer den Min gegen den Max Wert einer Groupe. Desto größer die Gruppe, desto mehr Vergleiche müssen gerechnet werden. Das könnte dann doch Sinn ergeben.

Als nächstes schaue ich mir Difference vs. Spread an
VG, Sven - TWS 950Q ID:335 & 291, VPN offen, Reboot OK

Robosoc
Reactions:
Beiträge: 1876
Registriert: Di Okt 09, 2018 9:26 am
Hat sich bedankt: 635 Mal
Danksagung erhalten: 775 Mal

#7

Beitrag von Robosoc »

Meine Vermutung hat sich bestätigt: Difference(last(val)) anstelle von spread(val) führt zu deutlich kleineren Ladezeiten bei gleichem Ergebnis (also bei Zählern, die nur in eine Richtung zählen ist das Ergebnis gleich)...es lohnt sich also - wenn man wirklich an dieser stelle Performance rausholen will - Difference statt Spread zu nutzen.

In einem Vergleich bei mir (Beispiel wie oben in #4 beschrieben und MinInterval = 1M) hatte ich folgende Vergleichzahlen:
Difference(last(val)): 0,64 s
spread(val): 1,97 s

...Als nächstes beantworte ich mal die eigentliche Frage von Dominic :doh:
Zuletzt geändert von Robosoc am Mi Jan 13, 2021 7:50 pm, insgesamt 1-mal geändert.
VG, Sven - TWS 950Q ID:335 & 291, VPN offen, Reboot OK

Robosoc
Reactions:
Beiträge: 1876
Registriert: Di Okt 09, 2018 9:26 am
Hat sich bedankt: 635 Mal
Danksagung erhalten: 775 Mal

#8

Beitrag von Robosoc »

cheater hat geschrieben: Di Jan 28, 2020 10:00 am Select "last()" [...] Hat man dies eingetragen wird nur noch ein Wert abgerufen. Kann mir das Jemand bitte bestätigen?
Das kann ich nach meinem Test in Grafana 7.2. nicht bestätigen. Ich habe zwei Panels vom Typ "Stat", welches meines Wissens der Nachfolger von Single Stat ist, angelegt. Beide Panels sind gleich mit Ausnahme der Funktion innerhalb SELECT.
Einmal habe ich Distinct() genutzt und einmal habe ich Last() genutzt.
Beide Ladezeiten waren nahezu identisch mit miniVorteil bei Last(). 1,16 s gegen 1,10s.

Beide Queries laden die gleiche Anzahl von Zeilen! Zumindest in der InfluxDB Version, die im TWS1.6 verwendet wird.


Ich beende dann mal meine Spielereien, die vermutlich keinem was bringen :-)
VG, Sven - TWS 950Q ID:335 & 291, VPN offen, Reboot OK

gbglace
Reactions:
Beiträge: 3585
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1253 Mal
Danksagung erhalten: 1649 Mal

#9

Beitrag von gbglace »

doch doch, ich finde sowas immer spannend.

gibt nur leider schon wieder Ansatzpunkte für mehr Arbeit bei Elabnet, das man da auch die DB noch auf min 1.8 bekommt um allein auch 1M nutzen zu können.
Grüße
Göran

#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension

Robosoc
Reactions:
Beiträge: 1876
Registriert: Di Okt 09, 2018 9:26 am
Hat sich bedankt: 635 Mal
Danksagung erhalten: 775 Mal

#10

Beitrag von Robosoc »

Das ist ja zum Glück für die TWS V2.0 eh in Planung, deshalb hatte ich mir die InfluxDB V1. 8 Change Log angeschaut. . :bow-yellow:
Zuletzt geändert von Robosoc am Do Jan 14, 2021 6:55 am, insgesamt 2-mal geändert.
VG, Sven - TWS 950Q ID:335 & 291, VPN offen, Reboot OK
Antworten

Zurück zu „Zeitserien, Logging & Grafana“