[vz-dev] Performanceoptimierung MeterInterpreter

[Andreas Goetz]

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....
>
>
>