Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam

2013-09-17 Diskussionsfäden Andreas Goetz 
Hi Sven,hast Du den aktuellen Stand aus dem Git? Wenn ja- um welchen
Sensortyp handelt es sich?

vg
Andreas

2013/9/17 Sven peitz sven.pe...@gmx.net

  Am 16.09.2013 20:45, schrieb Andreas Goetz:

 Hallo Rainer,

 2013/9/16 Rainer Gauweiler volkszaeh...@moppl.inka.de

 Hallo zusammen,

 Am 16.09.2013 16:41, schrieb Andreas Goetz:

 Hallo Thorben,

 2013/9/16 Thorben Thuermer r...@constancy.org mailto:
 r...@constancy.org


 On Mon, 16 Sep 2013 14:01:31 +0200
   Jakob Hirsch j...@plonk.de mailto:j...@plonk.de wrote:
   Sven peitz, 2013-09-14 11:07:
$result1=mysql_query(SELECT value FROM data WHERE id = (select
 max(id)
FROM data WHERE channel_id LIKE  '14'));...
   Allerdings sollte man nicht ohne Grund direkt auf der DB
 arbeiten. Das
   Vorgehen wie von Andreas Götz ist auch deutlich einfacher
 (Abfrage mit
   from=now).

 from=now...
 funktioniert doch aber wie gehabt nur bei erfassung absoluter
 staende.
 ansonsten war die methode doch from=x seconds ago...?
 also so, dass im im angegebenen zeitraum (mit now = nur aktuelle
 sekunde)
 genug werte erfasst sind, damit der interpreter in der middleware
 daraus etwas berechnen kann.
 also bei s0-zaehlern mindestens zwei impulse, etc...
 oder wurde da middleware-seitig was geandert?

 - Thorben


 Das sollte funktionieren da die MW (schon immer?) mittels zweier
 SQL-Queries den jeweils letzten und nächsten Datenpunkt außer des
 angefragten Zeitraumes ermitteln und from... to... entsprechend
 erweitern. Für now() gäbe es also immer den aktuellen und letzten
 Timestamp und damit die Möglichkeit einen aktuellen Periodenverbrauch zu
 berechnen.


 Tut bei mir nicht und tat es noch nie:

 {version:0.2,data:{uuid:*snip*,average:0,consumption:0,rows:0}}

 Wir hatten da auch auf dem Raspi Probleme und haben damals den Zeitraum
 erweitert, damit sicher Daten da waren.

 Aber gab es nicht auch kürzlich einen Patch der das Verhalten gebaut
 hat? Meine Installation hier ist ca ein Jahr alt.


  Du hast Recht. Was ich geschrieben habe stimmt zwar, allerdings ist der
 Code noch nicht im Repository angekommen, sondern steht noch in meinem Pull
 Request: https://github.com/volkszaehler/volkszaehler.org/pull/47
  Das Problem ist, dass die MW ohne diese Fixes je nach Sensortyp auch mal
 3 Tuple braucht um etwas sinnvolles zu liefern. Mit Pull Request sind es
 immer genau zwei Tupel die benötigt werden, damit klappt dann auch die
 Abfrage per now. now - x seconds ist keine allgemeingültige Lösung da
 man ja nicht wissen kann wann ein Sensor Daten liefert...

 vg
  Andreas

   Hallo,
 vielen Dank für eure Antworten,.
 seit eben ist mein sql Zugang beim Provider wieder frei und ich kann
 weiter testen.

 Ein from=now bringt bei mit folgendes:

 {version:0.2,data:{uuid:**snip**,average:0,consumption:0,rows:0}}



 Ein select value from data where channel_id=14 order by timestamp desc
 limit 1;

 ist wirklich schnell und bring den aktuellen Wert zu Tage.
 Ich hoffe mein Provider fühlt sich damit nicht wieder überlastet.
 Ein from=3seconds%20ago funktioniert auch und ist schnell.
 Mal sehen was geschickter Weise zu verwenden ist.

 Viele Grüße
 Sven

Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam

2013-09-17 Diskussionsfäden Andreas Goetz 
Hi Sven,

hast Du den aktuellen Stand aus dem Git? Wenn ja- um welchen Sensortyp
handelt es sich?

vg
Andreas


2013/9/17 Sven peitz sven.pe...@gmx.net

  Am 16.09.2013 20:45, schrieb Andreas Goetz:

 Hallo Rainer,

 2013/9/16 Rainer Gauweiler volkszaeh...@moppl.inka.de

 Hallo zusammen,

 Am 16.09.2013 16:41, schrieb Andreas Goetz:

 Hallo Thorben,

 2013/9/16 Thorben Thuermer r...@constancy.org mailto:
 r...@constancy.org


 On Mon, 16 Sep 2013 14:01:31 +0200
   Jakob Hirsch j...@plonk.de mailto:j...@plonk.de wrote:
   Sven peitz, 2013-09-14 11:07:
$result1=mysql_query(SELECT value FROM data WHERE id = (select
 max(id)
FROM data WHERE channel_id LIKE  '14'));...
   Allerdings sollte man nicht ohne Grund direkt auf der DB
 arbeiten. Das
   Vorgehen wie von Andreas Götz ist auch deutlich einfacher
 (Abfrage mit
   from=now).

 from=now...
 funktioniert doch aber wie gehabt nur bei erfassung absoluter
 staende.
 ansonsten war die methode doch from=x seconds ago...?
 also so, dass im im angegebenen zeitraum (mit now = nur aktuelle
 sekunde)
 genug werte erfasst sind, damit der interpreter in der middleware
 daraus etwas berechnen kann.
 also bei s0-zaehlern mindestens zwei impulse, etc...
 oder wurde da middleware-seitig was geandert?

 - Thorben


 Das sollte funktionieren da die MW (schon immer?) mittels zweier
 SQL-Queries den jeweils letzten und nächsten Datenpunkt außer des
 angefragten Zeitraumes ermitteln und from... to... entsprechend
 erweitern. Für now() gäbe es also immer den aktuellen und letzten
 Timestamp und damit die Möglichkeit einen aktuellen Periodenverbrauch zu
 berechnen.


 Tut bei mir nicht und tat es noch nie:

 {version:0.2,data:{uuid:*snip*,average:0,consumption:0,rows:0}}

 Wir hatten da auch auf dem Raspi Probleme und haben damals den Zeitraum
 erweitert, damit sicher Daten da waren.

 Aber gab es nicht auch kürzlich einen Patch der das Verhalten gebaut
 hat? Meine Installation hier ist ca ein Jahr alt.


  Du hast Recht. Was ich geschrieben habe stimmt zwar, allerdings ist der
 Code noch nicht im Repository angekommen, sondern steht noch in meinem Pull
 Request: https://github.com/volkszaehler/volkszaehler.org/pull/47
  Das Problem ist, dass die MW ohne diese Fixes je nach Sensortyp auch mal
 3 Tuple braucht um etwas sinnvolles zu liefern. Mit Pull Request sind es
 immer genau zwei Tupel die benötigt werden, damit klappt dann auch die
 Abfrage per now. now - x seconds ist keine allgemeingültige Lösung da
 man ja nicht wissen kann wann ein Sensor Daten liefert...

 vg
  Andreas

   Hallo,
 vielen Dank für eure Antworten,.
 seit eben ist mein sql Zugang beim Provider wieder frei und ich kann
 weiter testen.

 Ein from=now bringt bei mit folgendes:

 {version:0.2,data:{uuid:**snip**,average:0,consumption:0,rows:0}}



 Ein select value from data where channel_id=14 order by timestamp desc
 limit 1;

 ist wirklich schnell und bring den aktuellen Wert zu Tage.
 Ich hoffe mein Provider fühlt sich damit nicht wieder überlastet.
 Ein from=3seconds%20ago funktioniert auch und ist schnell.
 Mal sehen was geschickter Weise zu verwenden ist.

 Viele Grüße
 Sven

Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam

2013-09-17 Diskussionsfäden Sven peitz 

Am 16.09.2013 20:45, schrieb Andreas Goetz:

Hallo Rainer,

2013/9/16 Rainer Gauweiler volkszaeh...@moppl.inka.de 
mailto:volkszaeh...@moppl.inka.de


Hallo zusammen,

Am 16.09.2013 16:41, schrieb Andreas Goetz:

Hallo Thorben,

2013/9/16 Thorben Thuermer r...@constancy.org
mailto:r...@constancy.org mailto:r...@constancy.org
mailto:r...@constancy.org


On Mon, 16 Sep 2013 14:01:31 +0200
Jakob Hirsch j...@plonk.de mailto:j...@plonk.de
mailto:j...@plonk.de mailto:j...@plonk.de wrote:
  Sven peitz, 2013-09-14 11:07:
   $result1=mysql_query(SELECT value FROM data WHERE id
= (select
max(id)
   FROM data WHERE channel_id LIKE  '14'));...
  Allerdings sollte man nicht ohne Grund direkt auf der DB
arbeiten. Das
  Vorgehen wie von Andreas Götz ist auch deutlich einfacher
(Abfrage mit
  from=now).

from=now...
funktioniert doch aber wie gehabt nur bei erfassung
absoluter staende.
ansonsten war die methode doch from=x seconds ago...?
also so, dass im im angegebenen zeitraum (mit now = nur
aktuelle
sekunde)
genug werte erfasst sind, damit der interpreter in der
middleware
daraus etwas berechnen kann.
also bei s0-zaehlern mindestens zwei impulse, etc...
oder wurde da middleware-seitig was geandert?

- Thorben


Das sollte funktionieren da die MW (schon immer?) mittels zweier
SQL-Queries den jeweils letzten und nächsten Datenpunkt außer des
angefragten Zeitraumes ermitteln und from... to... entsprechend
erweitern. Für now() gäbe es also immer den aktuellen und letzten
Timestamp und damit die Möglichkeit einen aktuellen
Periodenverbrauch zu
berechnen.


Tut bei mir nicht und tat es noch nie:

{version:0.2,data:{uuid:*snip*,average:0,consumption:0,rows:0}}

Wir hatten da auch auf dem Raspi Probleme und haben damals den
Zeitraum erweitert, damit sicher Daten da waren.

Aber gab es nicht auch kürzlich einen Patch der das Verhalten
gebaut hat? Meine Installation hier ist ca ein Jahr alt.


Du hast Recht. Was ich geschrieben habe stimmt zwar, allerdings ist 
der Code noch nicht im Repository angekommen, sondern steht noch in 
meinem Pull Request: 
https://github.com/volkszaehler/volkszaehler.org/pull/47
Das Problem ist, dass die MW ohne diese Fixes je nach Sensortyp auch 
mal 3 Tuple braucht um etwas sinnvolles zu liefern. Mit Pull Request 
sind es immer genau zwei Tupel die benötigt werden, damit klappt dann 
auch die Abfrage per now. now - x seconds ist keine 
allgemeingültige Lösung da man ja nicht wissen kann wann ein Sensor 
Daten liefert...


vg
Andreas


Hallo,
vielen Dank für eure Antworten,.
seit eben ist mein sql Zugang beim Provider wieder frei und ich kann 
weiter testen.


Ein from=now bringt bei mit folgendes:

{version:0.2,data:{uuid:**snip**,average:0,consumption:0,rows:0}}


Ein select value from data where channel_id=14 order by timestamp desc 
limit 1;


ist wirklich schnell und bring den aktuellen Wert zu Tage.
Ich hoffe mein Provider fühlt sich damit nicht wieder überlastet.
Ein from=3seconds%20ago funktioniert auch und ist schnell.
Mal sehen was geschickter Weise zu verwenden ist.

Viele Grüße
Sven

Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam

2013-09-16 Diskussionsfäden Jakob Hirsch 
Sven peitz, 2013-09-14 11:07:
 $result1=mysql_query(SELECT value FROM data WHERE id = (select max(id)
 FROM data WHERE channel_id LIKE  '14'));
...
 Diese Anfrage dauert ca. 6-7 Sekunden. Hat jemand eine Idee wie man
 dieses beschleunigen kann?

Der subquery macht einen table-scan über die komplette data-Tabelle, was
dauert natürlich entsprechend lange. So ist es kein Problem (wenn auch
nicht schön):

SELECT value FROM data WHERE channel_id=14 AND timestamp=(select
max(timestamp) FROM data WHERE channel_id=14);

Allerdings sollte man nicht ohne Grund direkt auf der DB arbeiten. Das
Vorgehen wie von Andreas Götz ist auch deutlich einfacher (Abfrage mit
from=now).

Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam

2013-09-16 Diskussionsfäden Thorben Thuermer 
On Mon, 16 Sep 2013 14:01:31 +0200
Jakob Hirsch j...@plonk.de wrote:
 Sven peitz, 2013-09-14 11:07:
  $result1=mysql_query(SELECT value FROM data WHERE id = (select max(id)
  FROM data WHERE channel_id LIKE  '14'));
 ...
  Diese Anfrage dauert ca. 6-7 Sekunden. Hat jemand eine Idee wie man
  dieses beschleunigen kann?
 
 Der subquery macht einen table-scan über die komplette data-Tabelle, was
 dauert natürlich entsprechend lange.

achso, es gibt keinen index auf `id`...
den scan macht dann aber die haupt-query, nich die subquery.

 So ist es kein Problem (wenn auch nicht schön):
 SELECT value FROM data WHERE channel_id=14 AND timestamp=(select
 max(timestamp) FROM data WHERE channel_id=14);

wie schon gesagt, man wuerde doch eleganter schreiben:
select value from data where channel_id=14 order by timestamp desc limit 1;

 Allerdings sollte man nicht ohne Grund direkt auf der DB arbeiten. Das
 Vorgehen wie von Andreas Götz ist auch deutlich einfacher (Abfrage mit
 from=now).

from=now...
funktioniert doch aber wie gehabt nur bei erfassung absoluter staende.
ansonsten war die methode doch from=x seconds ago...?
also so, dass im im angegebenen zeitraum (mit now = nur aktuelle sekunde)
genug werte erfasst sind, damit der interpreter in der middleware
daraus etwas berechnen kann.
also bei s0-zaehlern mindestens zwei impulse, etc...
oder wurde da middleware-seitig was geandert?

- Thorben

Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam

2013-09-16 Diskussionsfäden Andreas Goetz 
Hallo Thorben,

2013/9/16 Thorben Thuermer r...@constancy.org

 On Mon, 16 Sep 2013 14:01:31 +0200
 Jakob Hirsch j...@plonk.de wrote:
  Sven peitz, 2013-09-14 11:07:
   $result1=mysql_query(SELECT value FROM data WHERE id = (select max(id)
   FROM data WHERE channel_id LIKE  '14'));...
  Allerdings sollte man nicht ohne Grund direkt auf der DB arbeiten. Das
  Vorgehen wie von Andreas Götz ist auch deutlich einfacher (Abfrage mit
  from=now).

 from=now...
 funktioniert doch aber wie gehabt nur bei erfassung absoluter staende.
 ansonsten war die methode doch from=x seconds ago...?
 also so, dass im im angegebenen zeitraum (mit now = nur aktuelle sekunde)
 genug werte erfasst sind, damit der interpreter in der middleware
 daraus etwas berechnen kann.
 also bei s0-zaehlern mindestens zwei impulse, etc...
 oder wurde da middleware-seitig was geandert?

 - Thorben


Das sollte funktionieren da die MW (schon immer?) mittels zweier
SQL-Queries den jeweils letzten und nächsten Datenpunkt außer des
angefragten Zeitraumes ermitteln und from... to... entsprechend erweitern.
Für now() gäbe es also immer den aktuellen und letzten Timestamp und damit
die Möglichkeit einen aktuellen Periodenverbrauch zu berechnen.

vg
Andreas

Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam

2013-09-16 Diskussionsfäden Justin Otherguy 
Hi,

Am 16.09.2013 um 20:45 schrieb Andreas Goetz:

 Du hast Recht. Was ich geschrieben habe stimmt zwar, allerdings ist der Code 
 noch nicht im Repository angekommen, sondern steht noch in meinem Pull 
 Request: https://github.com/volkszaehler/volkszaehler.org/pull/47
sodele - ist nun drin. Sorry für die Verzögerung - Beta-Tester wären praktisch 
*hint*

Anders formuliert:
bitte testen und beschweren, wenn etwas kaputt ist.

@Andreas: fettes Merci für's Patchen!!!


Gruss, J.

Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam

2013-09-16 Diskussionsfäden Patrik Karisch 
Servus,

Am 16. September 2013 20:53 schrieb Justin Otherguy 
jus...@justinotherguy.org:

 sodele - ist nun drin. Sorry für die Verzögerung - Beta-Tester wären
 praktisch *hint*

 Anders formuliert:
 bitte testen und beschweren, wenn etwas kaputt ist.

Für das wären Unit-Tests und ein CI-Server gedacht ^^ - travis-ci.org

Zumindestens für die großteil einer Applikation.

bg

Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam

2013-09-15 Diskussionsfäden Sven peitz 

Hallo,

leider kann ich derzeit nicht weiter testen, weil mein Provider den 
Zugriff wegen zu hoher SQL Last gesperrt hat.  ;-(

[X] MySQL-Last (Wartezeit auf Festplattenzugriff)

[X] MySQL-Last lesend (SELECT-Statements)

[X] Kontinuierlich hohe Last

Also sind die 6 Sekunden verursacht durch Auslastung des Servers.
Dem Vorschlag kann ich jetzt nicht folgen. SQL ist nicht mein täglich 
Brot ;-)


Select value where channel order by id desc limit 1


Aber den Vorschlag über die Middleware zu gehen würde ich gerne 
aufgreifen wenn ich wüsste wie.


Eigentlich brauche ich ja nur den zuletzt in der Datenbank eingetragenen 
Wert zur ID.

Ich muss jetzt aber erst mal warten bis der Zugriff wieder frei ist.

Gruß
Sven

Am 14.09.2013 11:40, schrieb Thorben Thuermer:

On Sat, 14 Sep 2013 11:07:20 +0200
Sven peitz sven.pe...@gmx.net wrote:

für mein neues Verbrauchs oder Vergleichsanzeige Projekt der aktuellen
PV Einspeisung und Bezug vom EVU frage ich in einem PHP script die
Volkszähler Datenbank ab.

[...]

$result1=mysql_query(SELECT value FROM data WHERE id = (select max(id)
FROM data WHERE channel_id LIKE  '14'));

auch zu beachten,
was genau in data.value steht ist vom channel-type abhaengig...
diese loesung funktioniert nur, wenn leistungswerte geloggt werden.


Diese Anfrage dauert ca. 6-7 Sekunden. Hat jemand eine Idee wie man
dieses beschleunigen kann?

die anfrage ohne subquery formulieren?
(subqueries sind fuer nicht sql-er zwar oft intuitiver,
  aber meist nicht effizient.)

select value where channel order by id desc limit 1


Gruß
Sven

- Thorben

Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam

2013-09-15 Diskussionsfäden Andreas Goetz 
Hallo Sven,

sowas in der Form sollte helfen:

http://host/middleware.php/data/8f20eb60-60df-11e2-81a1-3d3a387429e.json?from=now

vg
Andreas


2013/9/15 Sven peitz sven.pe...@gmx.net

  Hallo,

 leider kann ich derzeit nicht weiter testen, weil mein Provider den
 Zugriff wegen zu hoher SQL Last gesperrt hat.  ;-(
 [X] MySQL-Last (Wartezeit auf Festplattenzugriff)

 [X] MySQL-Last lesend (SELECT-Statements)

 [X] Kontinuierlich hohe Last

 Also sind die 6 Sekunden verursacht durch Auslastung des Servers.
 Dem Vorschlag kann ich jetzt nicht folgen. SQL ist nicht mein täglich Brot
 ;-)

 Select value where channel order by id desc limit 1



 Aber den Vorschlag über die Middleware zu gehen würde ich gerne aufgreifen
 wenn ich wüsste wie.

 Eigentlich brauche ich ja nur den zuletzt in der Datenbank eingetragenen
 Wert zur ID.
 Ich muss jetzt aber erst mal warten bis der Zugriff wieder frei ist.

 Gruß
 Sven

 Am 14.09.2013 11:40, schrieb Thorben Thuermer:

 On Sat, 14 Sep 2013 11:07:20 +0200
 Sven peitz sven.pe...@gmx.net sven.pe...@gmx.net wrote:

  für mein neues Verbrauchs oder Vergleichsanzeige Projekt der aktuellen
 PV Einspeisung und Bezug vom EVU frage ich in einem PHP script die
 Volkszähler Datenbank ab.

  [...]

  $result1=mysql_query(SELECT value FROM data WHERE id = (select max(id)
 FROM data WHERE channel_id LIKE  '14'));

  auch zu beachten,
 was genau in data.value steht ist vom channel-type abhaengig...
 diese loesung funktioniert nur, wenn leistungswerte geloggt werden.


  Diese Anfrage dauert ca. 6-7 Sekunden. Hat jemand eine Idee wie man
 dieses beschleunigen kann?

  die anfrage ohne subquery formulieren?
 (subqueries sind fuer nicht sql-er zwar oft intuitiver,
  aber meist nicht effizient.)

 select value where channel order by id desc limit 1


  Gruß
 Sven

  - Thorben

Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam

2013-09-14 Diskussionsfäden Thorben Thuermer 
On Sat, 14 Sep 2013 11:07:20 +0200
Sven peitz sven.pe...@gmx.net wrote:
 für mein neues Verbrauchs oder Vergleichsanzeige Projekt der aktuellen 
 PV Einspeisung und Bezug vom EVU frage ich in einem PHP script die 
 Volkszähler Datenbank ab.
[...]
 $result1=mysql_query(SELECT value FROM data WHERE id = (select max(id) 
 FROM data WHERE channel_id LIKE  '14'));

auch zu beachten,
was genau in data.value steht ist vom channel-type abhaengig...
diese loesung funktioniert nur, wenn leistungswerte geloggt werden.

 Diese Anfrage dauert ca. 6-7 Sekunden. Hat jemand eine Idee wie man 
 dieses beschleunigen kann?

die anfrage ohne subquery formulieren?
(subqueries sind fuer nicht sql-er zwar oft intuitiver,
 aber meist nicht effizient.)

select value where channel order by id desc limit 1

 Gruß
 Sven

- Thorben

Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam

2013-09-14 Diskussionsfäden Florian Knodt 
Auch kann es helfen ein explain vor den SQL-Befehl zu setzen und sich die 
Analyse anzusehen - da sieht man recht schnell ob Teile ohne Index ablaufen, 
was meist in langsamen Abfragen endet. 
--
Mit freundlichen Grüßen  ||  Sincerely yours
Florian Knodt ·· Im Teich 11 ·· 56648 Saffig
www.adlerweb.info · www.56648.de · @adlerweb

Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam

2013-09-14 Diskussionsfäden Andreas Goetz 
Ich hatte ähnliche Probleme- Grund dabei war allerdings 1s Connect Time für
MySQL. Warum gehst Du für die Abfragen eigentlich nicht über die
Middleware? Dann klappts auch für alle Sensortypen!

vg
Andreas


2013/9/14 Florian Knodt f.kn...@yotaweb.de

 Auch kann es helfen ein explain vor den SQL-Befehl zu setzen und sich die
 Analyse anzusehen - da sieht man recht schnell ob Teile ohne Index
 ablaufen, was meist in langsamen Abfragen endet.
 --
 Mit freundlichen Grüßen  ||  Sincerely yours
 Florian Knodt ·· Im Teich 11 ·· 56648 Saffig
 www.adlerweb.info · www.56648.de · @adlerweb