[prev in list] [next in list] [prev in thread] [next in thread]
List: volkszaehler-dev
Subject: Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam
From: Sven peitz <sven.peitz () gmx ! net>
Date: 2013-09-17 19:16:09
Message-ID: 5238AA79.9070901 () gmx ! net
[Download RAW message or body]
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@gmx.net <mailto:sven.peitz@gmx.net>>
>
> Am 16.09.2013 20:45, schrieb Andreas Goetz:
>> Hallo Rainer,
>>
>> 2013/9/16 Rainer Gauweiler <volkszaehler@moppl.inka.de
>> <mailto:volkszaehler@moppl.inka.de>>
>>
>> Hallo zusammen,
>>
>> Am 16.09.2013 16:41, schrieb Andreas Goetz:
>>
>> Hallo Thorben,
>>
>> 2013/9/16 Thorben Thuermer <r00t@constancy.org
>> <mailto:r00t@constancy.org> <mailto:r00t@constancy.org
>> <mailto:r00t@constancy.org>>>
>>
>>
>> On Mon, 16 Sep 2013 14:01:31 +0200
>> Jakob Hirsch <jh@plonk.de <mailto:jh@plonk.de>
>> <mailto:jh@plonk.de <mailto:jh@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
[Attachment #3 (text/html)]
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Am 17.09.2013 20:41, schrieb Andreas
Goetz:<br>
</div>
<blockquote
cite="mid:CAD+a8MjAYgv=8ODcx08c26AtZVvfHJOmgrnvOxBygyVs=28+2g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>Hi Sven,<br>
<br>
</div>
hast Du den aktuellen Stand aus dem Git? Wenn ja- um welchen
Sensortyp handelt es sich?<br>
<br>
vg<br>
</div>
Andreas<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
2013/9/17 Sven peitz <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:sven.peitz@gmx.net"
target="_blank">sven.peitz@gmx.net</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Am 16.09.2013 20:45, schrieb Andreas Goetz:<br>
</div>
<div>
<div class="h5">
<blockquote type="cite">
<div dir="ltr">Hallo Rainer,<br>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2013/9/16 Rainer
Gauweiler <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:volkszaehler@moppl.inka.de"
\
target="_blank">volkszaehler@moppl.inka.de</a>></span><br> <blockquote \
class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Hallo
zusammen,<br>
<br>
Am 16.09.2013 16:41, schrieb Andreas
Goetz:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
Hallo Thorben,<br>
<br>
2013/9/16 Thorben Thuermer <<a
moz-do-not-send="true"
href="mailto:r00t@constancy.org"
target="_blank">r00t@constancy.org</a>
<mailto:<a moz-do-not-send="true"
href="mailto:r00t@constancy.org"
target="_blank">r00t@constancy.org</a>>>
<div><br>
<br>
On Mon, 16 Sep 2013 14:01:31 \
+0200<br> </div>
<div>
<div> Jakob Hirsch <<a
moz-do-not-send="true"
href="mailto:jh@plonk.de"
target="_blank">jh@plonk.de</a>
<mailto:<a moz-do-not-send="true"
href="mailto:jh@plonk.de"
target="_blank">jh@plonk.de</a>>>
wrote:<br>
> Sven peitz, 2013-09-14
11:07:<br>
> >
$result1=mysql_query("SELECT value
FROM data WHERE id = (select<br>
max(id)<br>
> > FROM data WHERE
channel_id LIKE '14')");...<br>
> Allerdings sollte man
nicht ohne Grund direkt auf der DB<br>
arbeiten. Das<br>
> Vorgehen wie von Andreas
Götz ist auch deutlich einfacher<br>
(Abfrage mit<br>
> from=now).<br>
<br>
from=now...<br>
funktioniert doch aber wie
gehabt nur bei erfassung absoluter
staende.<br>
ansonsten war die methode doch
"from=<x> seconds ago"...?<br>
also so, dass im im angegebenen
zeitraum (mit now = nur aktuelle<br>
sekunde)<br>
genug werte erfasst sind, damit
der interpreter in der middleware<br>
daraus etwas berechnen kann.<br>
also bei s0-zaehlern mindestens
zwei impulse, etc...<br>
oder wurde da middleware-seitig
was geandert?<br>
<br>
- Thorben<br>
<br>
<br>
Das sollte funktionieren da die MW
(schon immer?) mittels zweier<br>
SQL-Queries den jeweils letzten und
nächsten Datenpunkt außer des<br>
angefragten Zeitraumes ermitteln und
from... to... entsprechend<br>
erweitern. Für now() gäbe es also
immer den aktuellen und letzten<br>
Timestamp und damit die Möglichkeit
einen aktuellen Periodenverbrauch zu<br>
berechnen.<br>
</div>
</div>
</blockquote>
<br>
Tut bei mir nicht und tat es noch nie:<br>
{"version":"0.2","data":{"uuid":"*snip*","average":0,"consumption":0,"rows":0}}<br>
<br>
Wir hatten da auch auf dem Raspi Probleme
und haben damals den Zeitraum erweitert,
damit sicher Daten da waren.<br>
<br>
Aber gab es nicht auch "kürzlich" einen
Patch der das Verhalten gebaut hat? Meine
Installation hier ist ca ein Jahr alt.<br>
</blockquote>
<div><br>
</div>
<div>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: <a
moz-do-not-send="true"
\
href="https://github.com/volkszaehler/volkszaehler.org/pull/47"
\
target="_blank">https://github.com/volkszaehler/volkszaehler.org/pull/47</a><br> \
</div> <div>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...<br>
<br>
vg<br>
</div>
<div>Andreas<br>
</div>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
</div>
Hallo,<br>
vielen Dank für eure Antworten,.<br>
seit eben ist mein sql Zugang beim Provider wieder frei
und ich kann weiter testen.<br>
<br>
Ein from=now bringt bei mit folgendes:
<div class="im"><br>
<pre \
style="line-height:normal;text-indent:0px;letter-spacing:normal;text-align:start;font- \
variant:normal;text-transform:none;font-style:normal;white-space:pre-wrap;word-wrap:br \
eak-word;font-weight:normal;word-spacing:0px">{"version":"0.2","data":{"uuid":"*<b>snip</b>*","average":0,"consumption":0,"rows":0}}
</pre>
</div>
Ein select value from data where channel_id=14 order by
timestamp desc limit 1;<br>
<br>
ist wirklich schnell und bring den aktuellen Wert zu Tage.<br>
Ich hoffe mein Provider fühlt sich damit nicht wieder
überlastet.<br>
Ein from=3seconds%20ago funktioniert auch und ist schnell.
<br>
Mal sehen was geschickter Weise zu verwenden ist.<br>
<br>
Viele Grüße<span class="HOEnZb"><font color="#888888"><br>
Sven<br>
<br>
<br>
</font></span></div>
</blockquote>
</div>
<br>
</div>
</blockquote>
Hallo Andreas,<br>
<br>
nein ich habe schon bestimmt 1 Jahr kein Update mehr gemacht.<br>
Damals gab es nach jedem Update viel zu tun weil sich einiges
geändert hat.<br>
<br>
Aber evtl sollte ich es mal wagen ;-)<br>
<br>
Gruß<br>
Sven<br>
<br>
<br>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic