<div dir="ltr"><div><div><div><div>Hallo Zusammen,<br><br>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 <a href="https://github.com/volkszaehler/volkszaehler.org/pull/334">https://github.com/volkszaehler/volkszaehler.org/pull/334</a> hatte ich einen Fehler behoben, damit aber leider auch Performance deutlich runter gezogen.<br><br><a href="https://github.com/volkszaehler/volkszaehler.org/pull/360">https://github.com/volkszaehler/volkszaehler.org/pull/360</a> 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.<br><br></div>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.<br><br></div>Wenns passt wär das dann aber auch die schnellste Version die wir jemals hatten!<br><br></div>Viele Grüße,<br></div>Andreas<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-10-05 15:48 GMT+02:00 Andreas Goetz <span dir="ltr"><<a href="mailto:cpuidle@gmail.com" target="_blank">cpuidle@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Jakob, all,<br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2015-10-05 15:16 GMT+02:00 Jakob Hirsch <span dir="ltr"><<a href="mailto:jh@plonk.de" target="_blank">jh@plonk.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<span><br>
Andreas Goetz wrote on 2015-10-02 10:49:<br>
> ich beobachte aktuell ein paar Probleme mit der Performance bei Nutzung<br>
> der Aggregation Root Cause scheint darni zu bestehen dass alle Anfragen<br>
> auf die Aggregationstabelle ziemlich aufwändig Unix Timestamps (sec) in<br>
> VZ Timestamps (ms) hin- und herrechnen müssen.<br>
<br>
</span>Diese "VZ"-Timestamps waren im Nachhinein wohl keine so gute Idee. Man<br>
brauchte aber sub-second-Auflösung und Javascript möchte die Timestamps<br>
sowieso in diesem Format. Ansonsten hätte man double oder so benutzen<br>
und jeden Wert multiplizieren müssen (in der Middlware beim GET oder im<br>
Frontend).<br></blockquote><div><br></div></span><div>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 ;).<br><br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> Wenn wir- das wäre der Vorschlag- unser DB Schema auf Unix Timestamps<br>
> umstellen können und auf Sekundenauflösung gehen dann würden wir eine<br>
<br>
</span>Nein, damit gäbe es große Abweichungen bei der Leistung. Selbst wenn man<br>
nur einen Impuls alle 10 bis 11 Sekunden hat, wäre der Fehler im<br>
Extremfall 10%.<br></blockquote><div><br></div></span><div>Guter Punkt! <br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Neuere MySQL/MariaDB-Versionen können aber auch timestamps mit<br>
fractional seconds, evt. wäre das eine bessere Lösung.<br></blockquote><div><br></div></span><div>Muss ich anschauen. Gibts das schon auf Jessie?<br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> Für das API liesse sich das transparent halten oder- das wäre eigentlich<br>
<br>
</span>Dann mußt du aber auch mit MUL/DIV arbeiten...<br></blockquote><div><br></div></span><div>Wie gesagt- einmalig tut das nichtmal weh.<br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> mein Vorschlag- wir stellen auch das API auf Sekunden um. Der Change<br>
> würde die Kompatibilität von vzlogger bis zu jedem Client beeinflussen.<br>
<br>
</span>Das ist m.E. bei der Menge an benutzen Clients (insbesondere der<br>
Net-IOs, auch wenn man die m.E. eher nicht benutzen sollte) ein no-go.<br></blockquote><div><br></div></span><div>Ok.<br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Andere möglichkeit wäre eine Erweiterung der API: ts bleibt<br>
JS-timestamp, tsX (mit irgendwas sinnvollem für X) wären fractional.<br>
<br>
</blockquote></span></div><br></div><div class="gmail_extra">Ich überlege gerade:<br><br></div><div class="gmail_extra">1) entweder... statt ms in der DB etwas mit Faktor 1024 zu speichern- dann könnte man wenigstens shiften statt zu rechnen<br></div><div class="gmail_extra">2) gefällt mir grad sehr gut... in der Aggregate Tabelle noch eine TIMESTAMP Spalte hinzuzufügen. <br><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">Das muss ich mir mal anschauen...<br><br></div><div class="gmail_extra">Viele Grüße,<br></div><div class="gmail_extra">Andreas<br><br></div></div>
</blockquote></div><br></div>