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

Andreas Goetz cpuidle at gmail.com
Thu Jan 9 21:26:37 CET 2014


Hallo Heiko,

jetzt hatte ich extra den Schlepptop hochgefahren um Dich mit Diagnosetipps
zu versorgen und schon rennt die Mieze?! Aber lieber so als anders ;)

Viel Spass mit dem Tier,
Andreas

PS.: Logging brauchst Du egtl auch nicht- dafür gibts ja &debug=1 im
Querystring ;)



2014/1/9 Heiko Baumann <hbcs at gmx.de>

>
>
>> 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...?
>>
>
> ... das war dann wohl auch ein Hauptgrund für die Lahmheit: jetzt hab ich
> das mysql-logging abgedreht, und siehe da... miau.... ;)
> Das Logging kostet einfach zu viel Performance auf der kleinen Kiste...
>
> Also: Logging zugedreht... tataaaaa.... 11 Sek. für die Jahresansicht
> eines Temperatur-Channels (allerdings nur Werte aus dem 2. Halbjahr) - das
> ist cool..
>
> Sieht gut aus, vielen Dank!!
> Schönen Abend...
> Heiko
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20140109/82b30ef3/attachment-0001.html>


More information about the volkszaehler-dev mailing list