<div dir="ltr"><div><div><div>Ich habe schon über ähnliche Lösungen nachgedacht- sei es als "virtueller" Kanal oder transparent als irgendwie ausgeprägte interne Statistiktabelle. Letztlich bin ich davon abgekommen da der Anwendungsfall sehr spezifisch ist- summiert man jetzt nach Stunden, Wochen oder Tagen?<br>
</div><br>Eine Verbesserung der Performance sollte bereits der aktuell im VZ liegende Pull Request bringen da damit ein Teil der Middleware-Arbeit von PHP in die Datenbank verschoben wird, bei group=... Anfragen ist dies jetzt schon der Fall.<br>
<br></div>Letztlich stellt sich die Frage "wofür"- was spricht dagegen bei Altdaten von vzcompress2 auf Tagesebene komprimieren zu lassen. Damit bliebe sehr viel Spielraum bevor selbst die Datenbank eines RasPi ausgereizt wäre.<br>
<br></div>Nur meine 2 cent...<br><br>Viele Grüsse,<br>Andreas<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/8/7 Heiko Baumann <span dir="ltr"><<a href="mailto:hbcs@gmx.de" target="_blank">hbcs@gmx.de</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hallo zusammen,<br>
<br>
ich greife mal wieder den aktuellen Gedanken zum Thema Performanceoptimierung auf.<br>
<br>
Hintergrund: es fallen in der DB ja doch recht viele Daten an, die im Laufe der Zeit mit der vorhandenen feinen Auflösung nicht benötigt werden.<br>
Abhilfe:  ich hab seit ein paar Tagen vzcompress2.php als cronjob laufen, das funktioniert bislang zumindest gut, keine Probleme erkennbar (User "vz" muss delete-permission auf die DB bekommen). Hab das wiki-Tutorial entsprechend ergänzt (<a href="http://wiki.volkszaehler.org/howto/raspberry_pi_image" target="_blank">http://wiki.volkszaehler.org/<u></u>howto/raspberry_pi_image</a>).<br>

<br>
Möchte ich aber wissen, wie hoch der  Zählerstand z.B. am 1.8. war und der Zähler seit 1.1. läuft, müsste ich  meines Wissens nach aktuell ja den kompletten Zeitraum 1.1. bis 1.8. im Frontend wählen und den rapsi dort lange lange rechnen lassen - meine DB ist nach einer Neuinstallation derzeit noch klein (70MB) und schafft das, aber ich befürchte, dass das über mehrere Monate nicht funktionieren würde.<br>

<br>
Idee (denke das wurde auch schon mal vorgeschlagen): der kumulierte Tageszähler läuft als eigener virtueller Channel, der alle x Sekunden (wohl eher 60 x 60 x 24 für einmal täglich) den vorherigen Stand plus Verbrauch innerhalb dieses Intervalls speichert. Somit könnte ich beliebig Monats- oder Jahresverbräuche mit minimalem Ressourcenbedarf bestimmen.<br>

<br>
Frage: gibts sowas schon? Ich verwende Udos Erweiterung mit S0 und 1wire Sensoren auf Basis eines frischen wheezy mit manueller vz-Installation.<br>
Oder hat jemand einen Tipp, wie ich anders an die gewünschten Summenwerte kommen kann?<br>
<br>
Vielen Dank für die Hilfe!<br>
LG Heiko<br>
<br>
</blockquote></div><br></div>