Hi Jakob,
Ich habs gemessen- bringt bei mir (5 Kanäle, Auflösung 5min, Raspi, Zoom
aufs Jahr, grosser Monitor=500 Tupel) 30% schnellere Antworten.
Mit dem Umbau auf feste Zeiträume wärs kein Thema mehr, habe es
allerdings nicht geschafft, das elegant in SQL zu realisieren. Wenn Du
da eine Idee hast helfe ich gerne.
Diff/ Pull Request ist kein Problem, wollte aber abwarten obs jemanden
interessiert.
Viele Grüsse,
Andreas
On 24.04.2013 18:47, Jakob Hirsch wrote:
Andreas Goetz, 24.04.2013 17:31:
beim Testen von VZ auf dem eher schwachbrüstigen Raspberry Pi ist mir
aufgefallen, dass Anfragen des Frontends nach einer bestimmten Anzahl
von Tupeln bei niedrigen Zoomstufen dadurch beantwortet werden, dass der
Interpreter durch alle Rows eines Resultsets läuft und diese gem. mit
Hilfe von packageSize auf die gewünschte Anzahl Tupel aggregiert. Dabei
Ja, damit nur die benötigte Anzahl von Tupeln übertragen werden muß. Das
Frontend kann ja eh nicht mehr darstellen.
müssen zum einen recht viele Daten verarbeitet werden, zum anderen diese
auch erstmal aus MySQL abgeholt werden.
Ja. Wobei das Problem dabei, wie bei Datenbanken meistens, die IO ist,
weil alle rows erstmal von der Platte gelesen werden müssen.
Alternativ lassen sich die Daten jedoch bereits in MySQL aggregieren.
Die untenstehende Methode erledigt das und kann in MeterInterpreter
eingefügt werden (siehe unterer Teil nach EmptyIterator).
Insofern ist es fraglich, ob das so wirklich schneller geht. In PHP ist
das allerdings auch nicht gerade hochperformant gelöst (mit callbacks
und Interface-Klasse).
Ein diff wäre übrigens nett, dann muß man nicht raussuchen, was da jetzt
anders ist.
Hast du denn mal gemesen, ob's damit wirklich signifikant schneller
geht? Also ein
time curl
'http://localhost/volkszaehler/middleware.php/data/deine-UUID.json?from=1366754400000&tuples=100'
mit beiden Methoden (mehrmals ausgeführt).
Abgesehen davon ist die aktuelle Implementierung sowieso nicht ganz
korrekt. Statt einer festen Anzahl von Rows pro Tupel müßte man
sinnvollerweise feste Zeiträume zusammenfassen. Der entsprechende Umbau
steht schon länger auf meiner Liste. Das könnte man aber allerdings auch
mit SQL machen....
