[vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam

[Sven peitz]

Am 16.09.2013 20:45, schrieb Andreas Goetz:
> Hallo Rainer,
>
> 2013/9/16 Rainer Gauweiler <volkszaehler at moppl.inka.de 
> <mailto:volkszaehler at moppl.inka.de>>
>
>     Hallo zusammen,
>
>     Am 16.09.2013 16:41, schrieb Andreas Goetz:
>
>         Hallo Thorben,
>
>         2013/9/16 Thorben Thuermer <r00t at constancy.org
>         <mailto:r00t at constancy.org> <mailto:r00t at constancy.org
>         <mailto:r00t at constancy.org>>>
>
>
>             On Mon, 16 Sep 2013 14:01:31 +0200
>             Jakob Hirsch <jh at plonk.de <mailto:jh at plonk.de>
>         <mailto:jh at plonk.de <mailto:jh at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20130917/0c9b5503/attachment.html>