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

[Andreas Goetz]

Hi Heiko,

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.

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

vg
Andreas


2014/1/10 Andreas Goetz <cpuidle at gmail.com>

> Moin,
>
> 2014/1/9 Heiko Baumann <hbcs at gmx.de>
>
>> Am 09.01.2014 21:26, schrieb Andreas Goetz:
>>
>>  Hallo Heiko,...
>>>
>> PS.: Logging brauchst Du egtl auch nicht- dafür gibts ja &debug=1 im
>>> Querystring ;)
>>>
>> Hm, wie kann ich das dem Server beim Starten mit übergeben?
>>
>
> Davon war nicht die Rede. Mit Querystring meine ich das Ding im Browser in
> der URL hinter dem Fragezeichen. Einfach bei der Abfrage mit angeben!!
>
>
>> (/etc/init.d/mysql start &debug=1 oder wie? Nee funktioniert nicht. Aber
>> so: im laufenden Betrieb einfach eine mysql-shell aufmachen und dann  SET
>> GLOBAL general_log = 'ON', danach dann mit ... 'OFF' wieder ausschalten).
>>
>>  Beim 2. Nachdenken- 11s für 180 Werte (=Tage) ist _viel_ zu langsam.
>>> Kannst Du mal die Queries für diese eine Abfrage abschauen? Bei mir geht
>>> sowas in 1sec...
>>>
>>
>> Ok, was ich gemacht hab: startseite vz, erst mal alle Channels unsichtbar
>> gestellt, dann nur einen sichtbar gemacht. Logging an, auf "Jahresansicht"
>> geklickt, gewartet bis der Graph angezeigt wurde, dann logging aus. Ergibt
>> das angehängte Log.
>>
>
> Viel zu kompliziert. 1 Kanal, nur den Middlewarerequest anschauen. Im
> Browser, mit &debug=1. Dann schauen was/wo das wie lange dauert.
>
> Ok, der aggregate-Teil dauert wohl nur 3 Sekunden, der Rest wird von
>> s0-Ereignissen erzeugt.
>>
>
> d.h. Dein Raspi ist von endlosen S0-Ereignnisse zugemüllt? Wieviele pro
> Minute?
>
>  Also doch alles ok?
>>
>
> Es ist laaaaaaaangsam- aber anscheinend nicht Problem der Aggregation.
>
>
>>
>> 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
>>
>> Das ist offenbar ein s0-Eintrag (value=1 im channel 14, Stromzähler).
>>  Was mich wundert: warum muss der aufwändige join vorher ausgeführt werden?
>> Liefert bei mir z.B.
>>
>> +-----+--------------------------------------+-------+------
>> +------------+---------------------+---------+------------+
>> | id0 | uuid1                                | type2 | id3  | pkey4
>>  | value5              | class6  | entity_id7 |
>> +-----+--------------------------------------+-------+------
>> +------------+---------------------+---------+------------+
>> |  14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power |   71 | active
>> | 1                   | channel |         14 |
>> |  14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power |   70 | color
>>  | navy                | channel |         14 |
>> |  14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power |   69 | public
>> | 1                   | channel |         14 |
>> |  14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power |   67 | resolution
>> | 1000                | channel |         14 |
>> |  14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power |   72 | style
>>  | steps               | channel |         14 |
>> |  14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power |   68 | title
>>  | Strom-Ferienwohnung | channel |         14 |
>> +-----+--------------------------------------+-------+------
>> +------------+---------------------+---------+------------+
>> 6 rows in set (0.00 sec)
>>
>> Muss das wirklich vor jedem Insert sein?
>> Und danach werden _immer_ die Werte für resolution, active und public
>> "geupdatet" (Unnötig, sind die alten Werte)
>>
>
> 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.
>
> Was mich wundert sind Property Updates denn diese sind wirklich völlig
> sinnlos. War das auch mit alten VZ-Versionen (also noch vor Einführung
> Composer mit Doctrine 2.0) schon so? Die würde ich gerne loswerden...
>
> Da die Stromzähler ja mitunter heftig feuern (Wärmepumpe unter Last 4kWh,
>> PV-Wechselsrichter gern auch mal 12kWh), könnt ich mir vorstellen, dass das
>> ziemlich viel unnötige Queries auslöst.
>>
>> @ Hendrik, liest du vielleicht mit? s0vz ist ja dein Baby, oder..? ;)
>>
>
> 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...
>
> vg
> Andrea
>
>
>> Denke also dass alles passt. Werds mal beobachten wie sich die Zeiten und
>> Zahlen verhalten...
>>
>> DANKE und ne gute Nacht  :)
>>
>> Heiko
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20140110/c2b6fa18/attachment.html>