[vz-dev] Performanceoptimierung MeterInterpreter

[Jakob Hirsch]

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