[vz-dev] Performanceoptimierung MeterInterpreter

[Andreas Goetz]

Ich hab's Dir mal als Pull Request verpackt: 
https://github.com/jahir/volkszaehler.org/pull/1

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