Rendrera med pChart - timeout

[flyvert]

Hej.

På tips från riro laborerar jag med pChart, PHP & MySQL på en Raspberry som är kopplad till ett 1wirenät med diverse givare.

Det går "hyffsat" bra att rendrera med pChart - dock tar processningen lite mycket tid och jag åker på timeout i Apache när det tar mer än 30 sekunder att rita en graf.

Att hämta o rita 1440 värden (1 dag mätt i minuter) går bra, t.ex. luftrycket, men om jag vill slänga på ytterligare en kurva i samma bild, t.ex. luftfuktighet och antalet datapunkter uppgår till 2880 tar det för lång tid och Apache timear ut.

PHP Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/1wire/pChart/class/pImage.class.php on line 441

MySQL tabelldatat är indexerat o samma SQL-sats tar c:a 1 sekund att köra på kommandoraden.
Efter att SQL satsen returnerat till PHP tar Apache all tillgänglig CPU tid tills timeout.

Jag använder givetvis arrayer

Kod: Markera allt

...
while($row = mysql_fetch_array($Result))
 {
  /* Push the results of the query in an array */
  $timestamp[] = $row["Time"];
  $values[]    = $row["value"];
 }
...

Är prestandan inte bättre, eller gör jag något fel?
Synd när en Raspberry lätt hasplar ur sig HD material till en TV...

Måste man låta göra statiska kurvor med något tidsstyrt jobb (cron) o länka till dessa?

[riro]

Hur ser SQL-frågan ut och hur många rader får du tillbaka från den?

Misstänker att du får tillbaka för många rader, det är "ganska" onödigt att be pChart rendera 10tusen rader om du vill ha en bild som är tusen pixlar bred.
Lite labbande med antingen SQL-frågan eller arrayen är nog en bra ide.

Har själv haft liknande problem (jag pratar med SwitchKing's REST-api och det returnerar lite väl mycket data som man får filtrera lite i innan man skickar in det till pChart)

[ekdahl]

Tips: Använd ett grafrenderingsbibliotek som lägger renderingen på klienten istället, så behöver du ingen kraftfull serverdator. Du kan dessutom få skalbar storlek på graferna då.
T.ex. Flot, Chart.js eller Google Charts

[riro]

Så här gör jag via PHP mot SwitchKing:

Kod: Markera allt

$step = 0;
foreach($xml->RESTDataSourceValue as $entry) {
	if ($step >= 10) {
		$Timestamp = new DateTime($entry->Timestamp);
		$labels[] = $Timestamp->getTimestamp();
		$values[] = (double) $entry->Value;
		$step = 0;
	} else {
		$step ++;
	}
}

Sedan skickar jag det vidare till pChart, blir allså bara var 10e rad som renderas...

[flyvert]

Så här gör jag via PHP mot SwitchKing:

Kod: Markera allt

$step = 0;
foreach($xml->RESTDataSourceValue as $entry) {
	if ($step >= 10) {
		$Timestamp = new DateTime($entry->Timestamp);
		$labels[] = $Timestamp->getTimestamp();
		$values[] = (double) $entry->Value;
		$step = 0;
	} else {
		$step ++;
	}
}

Sedan skickar jag det vidare till pChart, blir allså bara var 10e rad som renderas...

Efter att ha borstat av mina halvtomhalvt bortglömda kunskaper i SQL fick jag igår fart på en stored procedure som beräknar tim- och dygnsmedelvärden. Istället för att plotta 1440 värden/dygn/kurva blir det nu 24 värden/dygn/kurva och så här kan timmedelvärden från en EDS0068 se ut (24 värden x 4 sensorer = 96 punkter).

Grafen tar inte alls lika lång tid att rendera, men upplösningen blir ju en helt annan...

Skall ge mig i kast med några av dom andra lösningarna som föreslagits o sen bestämma mig för vilken metod jag väljer.
Dock är jag mycket sugen på att få elmätaren o en utegivare på plats - kan nog bli en beställning med lite mer givare vad det lider...

[riro]

Det går att använda datumstämpeln lite mer kreativt.

Helt otestad fråga, men ungefär så här:

Kod: Markera allt

SELECT
SUBSTRING(CAST(datumFältet AS NVARCHAR), 0,  ,15) as tid,
AVG(Värde)
FROM tabell
GROUP BY tid

Alltså att göra om datumstämpeln till en sträng och sedan kapa ner den, tar man då 15 tecken borde man få var 10'e minuts medelvärde.

Kod: Markera allt

2001-02-03 04:05:06
1234567890123456789

(edit: 15 ska det vara, inte 14)

[flyvert]

Intressant - skall prova. Är ganska rudis på MySQL (har endast jobbat med Oracle tidigare) men gillar på direkten möjligheterna att göra castning av data och möjligheten till tidjämförelser direkt i SQL-satsen utan att behöva gå via en uppsjö mer eller mindre kryptiska funktionsanrop.

Då diskutrymme o prestandan inte är "obegränsad" i RPi/MySQL tänker jag inte spara samtliga sensorers minutvärden för evigt.

Jag har implementerat stored procedures som räknar ut tim och dygnsmedelvärden (inkl max o min) o lagrar dessa i databasen - dessa medelvärden tänker jag nog behålla obegränsat medan minutdatat kommer jag att dumpa efter en viss period, 6 mån, 1 år, etc.

Fördelen att ha allt i tabellformat är ju att det går att låta applikationen "växa fram" över tiden. Har någon gång framöver tänkt räkna fram statistik över när "höst", "vinter", "vår" o "sommar" infallit (enl SMHIs princip) och se hur "årstiderna" rört på sig genom åren.

Drivmotorn bakom hela projektet (förutom att få meka med elektronik!) är till stor del sprunget ur att få mer input till vad som bidrar till mina energiräkningar (el, fjärrvärme).

[riro]

Jag har ungefär 30 miljoner mätvärden sparade (lagrar ungefär 10 tusen per dygn) och databasen är löjligt liten. Tror den ligger på ungefär 1Gb.
Jag hamstrar och bygger vyer.

Vem vet, någon gång kanske man behöver allt, tråkigt om man rensat då.