[vz-dev] Performance - Umstellung DB Schema

[Andreas Götz]

Moin Volker,

> Am 10.10.2015 um 20:02 schrieb Volker <v.ty at gmx.de>:
> 
> Hallo Andreas,
> 
> ich habe mit git pull aktualisiert.

Ehrm. Welchen branch? Den des PRs? Falls nein hast Du's auch nicht getestet ;)

> Bei mir sieht das gut aus, bisher ist mir kein Problem aufgefallen. Zur Performance kann ich nur so viel sagen, dass meine 4 S0 Zähler die in Minutenabständen geloggt werden nie mehr als 2 Sekunden brauchen bis die Grafik angezeigt wird - egal welches Zeitintervall angezeigt wird (Frontend und SQL auf BananaPi). Also bei mir ist alles ok.

Ich habs jetzt einfach committed- git pull reicht ab jetzt- wenns Probleme geben sollte steh ich ja Gewehr bei Fuß.

> Gruß
> Volker

Schönen Sonntag, Euer Andreas 

> 
>> Am 09.10.2015 um 12:54 schrieb 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
>> <mailto:cpuidle at gmail.com>>:
>> 
>>    Hi Jakob, all,
>> 
>>    2015-10-05 15:16 GMT+02:00 Jakob Hirsch <jh at plonk.de <mailto: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
>> 
>> 
> 
> -- 
> Volker Troyke
> Homepage: www.troyke.de
> E-Mail  : v.ty at gmx.de
>