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@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@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 <w3llschm...@gmail.com
<mailto:w3llschm...@gmail.com>>
Super Arbeit, läuft aum Raspi wie 'Schmidts Katze' !!!
Das hört man doch gerne ;) Hat sich die Arbeit gelohnt :))
