[vz-dev] Performance - Umstellung DB Schema

[Andreas Goetz]

Hallo Frank,

2015-10-05 19:13 GMT+02:00 Hr FS <mailing3000 at googlemail.com>:

> Hallo Kollegen,
> ich bekomme seit kurzem komische + und - Spikes in den Diagrammen des
> Demo-webfrontends zu sehen.
>

Was heisst das? Gibts die Spikes auch in alten Daten oder nur in neuen
Daten? Wenn letzteres liegt es sicher nicht an Frontend/Middleware. Hast Du
2 Beispiele? Wann hast Du zuletzt erwartetes Verhalten beobachtet?


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

Nein. Da dies hier das Entwicklerforum ist dikutieren wir erstmal was/wie
wir anpassen- genau das verfolgst Du gerade ;)


> Anbei ein screenshot. Früher waren die Sprünge immer recht smooth. Irgend
> etwas passt da nicht.
>

Ja, sieht für PV sehr seltsam aus. Finde ich aber z.B. in Daten für Juni
auch so.


> VG
> Frank
>

Viele Grüße,
Andreas


>
> 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/db02d7f8/attachment.html>