<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="gmail_quote">Guten Abend...<br>
<br>
<br>
> 1 Kanal, nur den Middlewarerequest anschauen. Im Browser, mit
&debug=1. Dann schauen was/wo das wie lange dauert. <br>
<br>
Ok. Für einen Kanal sind ja offenbar 3 Queries nötig:
von-Timestamp, bis-Timestamp und dann die eigentlichen Werte.<br>
Rattert gnadenlos schnell durch. Schmidts Katze ist ne Schildkröte
im Vergleich ;)<br>
<br>
<div>> d.h. Dein Raspi ist von endlosen S0-Ereignnisse
zugemüllt? Wieviele pro Minute? <br>
<br>
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.<br>
<br>
</div>
<div>> Es ist laaaaaaaangsam- aber anscheinend nicht Problem
der Aggregation.<br>
<br>
Zustimmung.<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-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>
</blockquote>
<br>
<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>
Ok.<br>
<br>
</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>
<div>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>
Ja, und genau diese Situation habe ich, dass s0 ordentlich Last
erzeugt. Heeeeeeeendriiiiik, kommst du mal eben bitte...? ;)<br>
<br>
Ich hoff mal er liest mit und meldet sich, sonst werd ich ihn
mal direkt anmailen.<br>
</div>
</div>
<br>
> schau doch mal ob Du mit diesem PR hier <a
moz-do-not-send="true"
href="https://github.com/volkszaehler/volkszaehler.org/pull/95">https://github.com/volkszaehler/volkszaehler.org/pull/95</a>
die überflüssigen SQLs für die properties Tabelle loswerden kannst.<br>
<br>
Probier ich gern aus...ähhhh... wenn du mir sagst, wie ich das
mache?<br>
<br>
> Löst aber nicht die (wichtigeren...) Probleme mit s0vz.<br>
<br>
Na jeder Fortschritt ist willkommen ;)<br>
<br>
cu.. Heiko<br>
<br>
</body>
</html>