<div dir="ltr">Hi Jakob, all,<br><div class="gmail_extra"><br><div class="gmail_quote">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 class=""><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><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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> 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><div>Guter Punkt! <br></div><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><div>Muss ich anschauen. Gibts das schon auf Jessie?<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> 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><div>Wie gesagt- einmalig tut das nichtmal weh.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> 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><div>Ok.<br> <br></div><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></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>