[vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository

[Heiko Baumann]

Guten Abend...


 > 1 Kanal, nur den Middlewarerequest anschauen. Im Browser, mit 
&debug=1. Dann schauen was/wo das wie lange dauert.

Ok. Für einen Kanal sind ja offenbar 3 Queries nötig: von-Timestamp, 
bis-Timestamp und dann die eigentlichen Werte.
Rattert gnadenlos schnell durch. Schmidts Katze ist ne Schildkröte im 
Vergleich ;)

 > d.h. Dein Raspi ist von endlosen S0-Ereignnisse zugemüllt? Wieviele 
pro Minute?

Ich fürchte ja. Attack of the killer s0-events. Ich hab "leider" einige 
s0-Zähler: PV-Wechselrichter (erzeugt wohl am meisten), Wärmepumpe (ist 
im Winter auch gut dabei, 20kWh am Tag?) und dann noch Stromzähler für 
Ferienwohnung und Hauptwohnung. Kommt insgesamt schon einiges zusammen.

 > Es ist laaaaaaaangsam- aber anscheinend nicht Problem der Aggregation.

Zustimmung.


    Kleine Anmerkung zu den s0-Ereignissen - ist aber andere Baustelle:
    im log fällt mir auf, dass das sehr häufig vorkommt:
                       911 Query     SELECT e0_.id AS id0, e0_.uuid AS
    uuid1, e0_.type AS type2, p1_.id AS id3, p1_.pkey AS pkey4,
    p1_.value AS value5, e0_.class AS class6, p1_.entity_id AS
    entity_id7 FROM entities e0_ LEFT JOIN properties p1_ ON e0_.id =
    p1_.entity_id WHERE (e0_.uuid =
    '90da22c0-f2dc-11e2-a59d-e9b55d71b128') AND e0_.class IN ('channel',
    'aggregator') ORDER BY p1_.pkey ASC
                       911 Query     START TRANSACTION
                       911 Query     INSERT INTO data (timestamp, value,
    channel_id) VALUES ('1389302896063', '1', 14)
                       911 Query     UPDATE properties SET value = '1'
    WHERE id = 71
                       911 Query     UPDATE properties SET value = '1'
    WHERE id = 69
                       911 Query     UPDATE properties SET value =
    '1000' WHERE id = 67
                       911 Query     commit


 > Den Join braucht Doctrine, das scheint auch mit Query Cache nicht weg 
optimierbar zu sein da es immer einen aktuellen Stand aus der DB haben 
will, die Abfrage ist auch schnell.

Ok.

 > Da liegt m.E. das Grundproblem. s0vz scheint nicht wie vzlogger eine 
eingebaute Datenaggregation zu haben bevor es an die Middleware geht. 
Das Thema gabs auch in anderen Threads schon.
Aus meiner Sicht ist das das Hauptproblem für die Perfprobleme wenn s0 
ordentlich Impulse liefert. Da müsste allerdigns der Autor ran, C ist 
nicht meine Welt...

Ja, und genau diese Situation habe ich, dass s0 ordentlich Last erzeugt. 
Heeeeeeeendriiiiik, kommst du mal eben bitte...? ;)

Ich hoff mal er liest mit und meldet sich, sonst werd ich ihn mal direkt 
anmailen.

 > schau doch mal ob Du mit diesem PR hier 
https://github.com/volkszaehler/volkszaehler.org/pull/95 die 
überflüssigen SQLs für die properties Tabelle loswerden kannst.

Probier ich gern aus...ähhhh... wenn du mir sagst, wie ich das mache?

 > Löst aber nicht die (wichtigeren...) Probleme mit s0vz.

Na jeder Fortschritt ist willkommen ;)

cu.. Heiko

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20140110/2d497d14/attachment.html>