<div dir="ltr">Moin,<br><div class="gmail_extra"><br><div class="gmail_quote">2014/1/9 Heiko Baumann <span dir="ltr"><<a href="mailto:hbcs@gmx.de" target="_blank">hbcs@gmx.de</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am 09.01.2014 21:26, schrieb Andreas Goetz:<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hallo Heiko,...<br>
</blockquote></div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
PS.: Logging brauchst Du egtl auch nicht- dafür gibts ja &debug=1 im Querystring ;)<br>
</blockquote></div>
Hm, wie kann ich das dem Server beim Starten mit übergeben?<br></blockquote><div><br></div><div>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!!<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(/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).<br>
<div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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...<br>
</blockquote>
<br></div>
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.<br>
</blockquote><div><br></div><div>Viel zu kompliziert. 1 Kanal, nur den Middlewarerequest anschauen. Im Browser, mit &debug=1. Dann schauen was/wo das wie lange dauert. <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Ok, der aggregate-Teil dauert wohl nur 3 Sekunden, der Rest wird von s0-Ereignissen erzeugt.<br></blockquote><div><br></div><div>d.h. Dein Raspi ist von endlosen S0-Ereignnisse zugemüllt? Wieviele pro Minute? <br><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Also doch alles ok?<br></blockquote><div><br></div><div>Es ist laaaaaaaangsam- aber anscheinend nicht Problem der Aggregation.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Kleine Anmerkung zu den s0-Ereignissen - ist aber andere Baustelle: im log fällt mir auf, dass das sehr häufig vorkommt:<br>
                  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-<u></u>e9b55d71b128') AND e0_.class IN ('channel', 'aggregator') ORDER BY p1_.pkey ASC<br>

                  911 Query     START TRANSACTION<br>
                  911 Query     INSERT INTO data (timestamp, value, channel_id) VALUES ('1389302896063', '1', 14)<br>
                  911 Query     UPDATE properties SET value = '1' WHERE id = 71<br>
                  911 Query     UPDATE properties SET value = '1' WHERE id = 69<br>
                  911 Query     UPDATE properties SET value = '1000' WHERE id = 67<br>
                  911 Query     commit<br>
<br>
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.<br>
<br>
+-----+-----------------------<u></u>---------------+-------+------<u></u>+------------+----------------<u></u>-----+---------+------------+<br>
| id0 | uuid1                                | type2 | id3  | pkey4      | value5              | class6  | entity_id7 |<br>
+-----+-----------------------<u></u>---------------+-------+------<u></u>+------------+----------------<u></u>-----+---------+------------+<br>
|  14 | 90da22c0-f2dc-11e2-a59d-<u></u>e9b55d71b128 | power |   71 | active     | 1                   | channel |         14 |<br>
|  14 | 90da22c0-f2dc-11e2-a59d-<u></u>e9b55d71b128 | power |   70 | color      | navy                | channel |         14 |<br>
|  14 | 90da22c0-f2dc-11e2-a59d-<u></u>e9b55d71b128 | power |   69 | public     | 1                   | channel |         14 |<br>
|  14 | 90da22c0-f2dc-11e2-a59d-<u></u>e9b55d71b128 | power |   67 | resolution | 1000                | channel |         14 |<br>
|  14 | 90da22c0-f2dc-11e2-a59d-<u></u>e9b55d71b128 | power |   72 | style      | steps               | channel |         14 |<br>
|  14 | 90da22c0-f2dc-11e2-a59d-<u></u>e9b55d71b128 | power |   68 | title      | Strom-Ferienwohnung | channel |         14 |<br>
+-----+-----------------------<u></u>---------------+-------+------<u></u>+------------+----------------<u></u>-----+---------+------------+<br>
6 rows in set (0.00 sec)<br>
<br>
Muss das wirklich vor jedem Insert sein?<br>
Und danach werden _immer_ die Werte für resolution, active und public "geupdatet" (Unnötig, sind die alten Werte)<br></blockquote><div><br></div><div>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.<br>
<br></div><div>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...<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
@ Hendrik, liest du vielleicht mit? s0vz ist ja dein Baby, oder..? ;)<br></blockquote><div><br></div><div>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.<br>
<br>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...<br><br></div><div>vg<br></div><div>Andrea<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Denke also dass alles passt. Werds mal beobachten wie sich die Zeiten und Zahlen verhalten...<br>
<br>
DANKE und ne gute Nacht  :)<span class="HOEnZb"><font color="#888888"><br>
<br>
Heiko<br>
</font></span></blockquote></div><br></div></div>