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

[Heiko Baumann]

Hi Andi...

>
>     http://vz/middleware.php/capabilities/database.json
>
>     liefert mir:
>
>     {"version":"0.3","capabilities":{"database":{"data_rows":6420892,"data_size":592134144,"aggregation_enabled":1,"aggregation_rows":58082,"aggregation_ratio":110.549}}}
>
>     ... also ist das doch offenbar richtig aktiviert
>
>
> Erstmal sind Daten drin. Ob die für die Kanäle drin sind die bei Dir 
> "langsam" sind sieht man daran nicht.

|select *, from_unixtime(timestamp/1000) from aggregate order by channel_id, timestamp


|

Untitled zeigt mir, dass für *alle* channels stündlich ein Wert 
vorhanden ist. Zudem gibts je einen Tageswert (type=3 nehme ich an).

>     Jedenfalls steht in volkszaehler.conf.php was von "administration
>     credentials" - ich gehe mal davon aus, dass ich für den user root
>     mein login-PW eintrage.
>
>
> Ganz sicher nicht?! Da kommt ein DB-User mit CREATE/DROP Privilegien 
> rein falls Dein normaler DB-User die nicht hat.
Hm, ich hab den Standarduser nicht geändert, also lass ich das 
default-PW drin, ok. Diese Geschichte ist mir auch erst gestern ganz 
spät nachts aufgefallen, da hab ich aggregate-Tabelle schon längst 
erzeugt. Habs gerade nochmal getestet, hast recht: mit meinem 
root-shell-PW gibts nen "access denied for user root..." Fehler. Klappt 
jetzt wieder:

pi at BauratPi ~ $ php /var/www/volkszaehler.org/misc/tools/aggregate.php 
-m full -l day -l hour run
Performing 'full' aggregation on 'day' level.
Updated 3999 rows.
Performing 'full' aggregation on 'hour' level.
Updated 83685 rows.

>
>     Die Timezone ("Europe/Berlin") ist rauskommentiert - soll das so sein?
>
>
> Eher nicht.
Ok, also Kommmentare raus. Done.

>
>
>     Tja und dann kommt also noch als letzte Zeile
>     $config['aggregation']=true;
>     mit rein. Speichern, aber selbst nach reboot kann ich keine
>     Beschleunigung erkennen.
>
>
> Reboot ist nicht nötig. Woran machst Du "keine Beschleunigung" das 
> fest? Bestimmte Abfrage? Nutzung des Frontends?
Ja, Nutzung des Frontends. Bei mir dauert nach wie vor eine Tagesabfrage 
ca. 10 Sekunden, für einen Monat ca. 80 Sekunden, da hat sich gar nichts 
geändert (Zeitangaben bei Ansicht mit allen 19 Channels).

>
>     Die aggregate-Tabellen wurden erzeugt und sind befüllt, hat bei
>     500MB data doch ganz schön gedauert.
>
>
> Macht nix. Für Deltabefüllung gibts ja dann den entsprechenden  Modus 
> womit's auch fix geht.
Klar, kein Thema. Nur hab ich mich jetzt auf Schmidts Katze gefreut, 
aber die mag nicht ;)
>
>
>     Woran könnte es liegen, dass die Performanceoptimierungen bei mir
>     nicht greifen?
>
>
> S.o.
...hmmmm.... leider wohl eher nicht. Menno, ich will aber die Katze 
rennen sehen... wie kann ich dem Fehler auf die Schliche kommen?

Bin jetzt echt am Grübeln - vielleicht läuft die Optimierung ja doch 
schon? hmmm... ahhh.. moment, ich schau einfach mal ins mysql.log. 
Tatsächlich: da wird fleissig auf die aggregate-Tabelle zugegriffen:
140109 20:37:15 70465 Connect   vz at localhost on volkszaehler
                 70465 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 = 
'9a7ed6c0-f2dc-11e2-b13e-b9abb50897a8') AND e0_.class IN ('channel', 
'aggregator') ORDER BY p1_.pkey ASC
                 70465 Query     SELECT MIN(timestamp) FROM (SELECT 
timestamp FROM data WHERE channel_id='15' AND timestamp<'1389209549459' 
ORDER BY timestamp DESC LIMIT 2) t
                 70465 Query     SELECT MAX(timestamp) FROM (SELECT 
timestamp FROM data WHERE channel_id='15' AND timestamp>'1389295949459' 
ORDER BY timestamp ASC LIMIT 2) t
                 70465 Query     SELECT aggregate.type, 
COUNT(aggregate.id) AS count FROM aggregate INNER JOIN entities ON 
aggregate.channel_id = entities.id WHERE uuid = 
'9a7ed6c0-f2dc-11e2-b13e-b9abb50897a8' GROUP BY type HAVING count > 0 
ORDER BY type DESC
                 70465 Query     SELECT 
UNIX_TIMESTAMP(FROM_UNIXTIME(MIN(timestamp) / 1000, "%Y-%m-%d")) * 1000 
FROM aggregate WHERE channel_id='15' AND type='3' AND 
timestamp>='1388227905662'
                 70465 Query     SELECT 
UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) / 1000, 
"%Y-%m-%d"), INTERVAL 1 day)) * 1000 FROM aggregate WHERE 
channel_id='15' AND type='3' AND timestamp<'1389296017384'
                 70465 Query     SELECT SUM(count) FROM (SELECT COUNT(1) 
AS count FROM data WHERE channel_id = '15' AND ( timestamp >= 
'1388227905662' AND timestamp < '1388185200000' OR timestamp >= 
'1388271600000' AND timestamp <= '1389296017384') UNION SELECT 
SUM(count) AS count FROM aggregate WHERE channel_id = '15' AND type = 
'3' AND timestamp >= '1388185200000' AND timestamp < '1388271600000') AS agg


...also alles richtig und muss damit leben, dass Schmidts Katze bei mir 
nicht mag...?

Danke...!
LG Heiko

>
>     Am 27.12.2013 18:22, schrieb Andreas Goetz:
>>     2013/12/27 W3ll Schmidt <w3llschmidt at gmail.com
>>     <mailto:w3llschmidt at gmail.com>>
>>
>>         Super Arbeit, läuft aum Raspi wie 'Schmidts Katze' !!!
>>
>>
>>     Das hört man doch gerne ;) Hat sich die Arbeit gelohnt :))
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20140109/7f731cc5/attachment.html>