[vz-dev] Performance - Umstellung DB Schema

[Andreas Goetz]

Hallo Zusammen,

erstmal sorry für den Sturm im Wasserglas. Ja, das DB-Schema ist nicht
optimimal für Performance, aber es ist auch kein riesen Drama! Mit
https://github.com/volkszaehler/volkszaehler.org/pull/334 hatte ich einen
Fehler behoben, damit aber leider auch Performance deutlich runter gezogen.

https://github.com/volkszaehler/volkszaehler.org/pull/360 macht das jetzt
wieder gut und bringt- kleines Goodie- noch ein paar Optimierungen mit die
bei häufig vorkommenden Anwendungsfällen nochmal 0,5-1s je Abfrage bringen.

Mir wärs trotzdem recht wenn ihr sorgfältig testen würdet, vor allem
@Gernot und @fostex die damit schon das ein oder andere Problem haben.

Wenns passt wär das dann aber auch die schnellste Version die wir jemals
hatten!

Viele Grüße,
Andreas


2015-10-05 15:48 GMT+02:00 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/20151009/458c1bef/attachment.html>