[vz-dev] Performance - Umstellung DB Schema

[Volker]

Hallo Andreas,

ich habe mit git pull aktualisiert. 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.

Gruß
Volker

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