[vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam

[Sven peitz]

Am 17.09.2013 20:41, schrieb 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.peitz at gmx.net <mailto:sven.peitz at gmx.net>>
>
>     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
>
>
>
Hallo  Andreas,

nein ich habe schon bestimmt 1 Jahr kein Update mehr gemacht.
Damals gab es nach jedem Update viel zu tun weil sich einiges geändert hat.

Aber evtl sollte ich es mal wagen ;-)

Gruß
Sven


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