ElabNET Technik Forum

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?

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

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.

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 .

Im Query Inspector sieht man auch jetzt (6.4.7) schon wie viele Arrays abgefragt wurden.

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

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

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

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.

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. .