[vz-dev] Performance - Umstellung DB Schema

[Hr FS]

Hallo Kollegen,
ich bekomme seit kurzem komische + und - Spikes in den Diagrammen des
Demo-webfrontends zu sehen. Geloggt wird mittels Udo's YPort (AVR 1284p)
und E6. Im E6 sind aufsummierte Impulse für ein 8s-Intervall eingestellt.
Hat das etwas mit der DB-Umstellung zu tun? Anbei ein screenshot. Früher
waren die Sprünge immer recht smooth. Irgend etwas passt da nicht.
VG
Frank

Am 5. Oktober 2015 um 15:48 schrieb Andreas Goetz <cpuidle at gmail.com>:

> Hi Jakob, all,
>
> 2015-10-05 15:16 GMT+02:00 Jakob Hirsch <jh at plonk.de>:
>
>> Hi!
>>
>> Andreas Goetz wrote on 2015-10-02 10:49:
>> > ich beobachte aktuell ein paar Probleme mit der Performance bei Nutzung
>> > der Aggregation Root Cause scheint darni zu bestehen dass alle Anfragen
>> > auf die Aggregationstabelle ziemlich aufwändig Unix Timestamps (sec) in
>> > VZ Timestamps (ms) hin- und herrechnen müssen.
>>
>> Diese "VZ"-Timestamps waren im Nachhinein wohl keine so gute Idee. Man
>> brauchte aber sub-second-Auflösung und Javascript möchte die Timestamps
>> sowieso in diesem Format. Ansonsten hätte man double oder so benutzen
>> und jeden Wert multiplizieren müssen (in der Middlware beim GET oder im
>> Frontend).
>>
>
> Die Multiplikation vor/nach JSON tut gar nicht so weh- richtig weh tut
> dass wir zwischendurch beim Zugriff auf die Aggregationstabelle _alle_
> Werte mit durchmultiplizieren müssen (Idee parken ;).
>
> > Wenn wir- das wäre der Vorschlag- unser DB Schema auf Unix Timestamps
>> > umstellen können und auf Sekundenauflösung gehen dann würden wir eine
>>
>> Nein, damit gäbe es große Abweichungen bei der Leistung. Selbst wenn man
>> nur einen Impuls alle 10 bis 11 Sekunden hat, wäre der Fehler im
>> Extremfall 10%.
>>
>
> Guter Punkt!
>
>>
>> Neuere MySQL/MariaDB-Versionen können aber auch timestamps mit
>> fractional seconds, evt. wäre das eine bessere Lösung.
>>
>
> Muss ich anschauen. Gibts das schon auf Jessie?
>
>
>> > Für das API liesse sich das transparent halten oder- das wäre eigentlich
>>
>> Dann mußt du aber auch mit MUL/DIV arbeiten...
>>
>
> Wie gesagt- einmalig tut das nichtmal weh.
>
>
>> > mein Vorschlag- wir stellen auch das API auf Sekunden um. Der Change
>> > würde die Kompatibilität von vzlogger bis zu jedem Client beeinflussen.
>>
>> Das ist m.E. bei der Menge an benutzen Clients (insbesondere der
>> Net-IOs, auch wenn man die m.E. eher nicht benutzen sollte) ein no-go.
>>
>
> Ok.
>
>
>> Andere möglichkeit wäre eine Erweiterung der API: ts bleibt
>> JS-timestamp, tsX (mit irgendwas sinnvollem für X) wären fractional.
>>
>>
> Ich überlege gerade:
>
> 1) entweder... statt ms in der DB etwas mit Faktor 1024 zu speichern- dann
> könnte man wenigstens shiften statt zu rechnen
> 2) gefällt mir grad sehr gut... in der Aggregate Tabelle noch eine
> TIMESTAMP Spalte hinzuzufügen.
>
> Bei 2) bliebe die Quellauflösung der Daten gleich und nur für besonders
> schnelle Abfragen, bei Bedarf auf auf Sekunden aggregiert, würden wir
> wirklcih allen Overhead rausnehmen.
>
> Das muss ich mir mal anschauen...
>
> Viele Grüße,
> Andreas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20151005/cb1d0fe0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20151005_vz_demo.jpg
Type: image/jpeg
Size: 98907 bytes
Desc: not available
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20151005/cb1d0fe0/attachment-0001.jpg>