<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
<br>Hallo <br><br>Angefangen hat es damit ( Thorben hat mir nen 'Bug' behoben ) siehe Unten<br>dann ging es nur noch um die Daten, (der vzlogger läuft seit dem Ohne Probleme) <br><br>aber rein von meinem 'Empfinden' hat sich mir der Class 10 keine Verbesserung ergeben .. <br>nur das diese laut der Abfrage ca. 2,5 mal schneller ist <br>merke ich im Frontend keine Verbesserung der Anzeigegeschwindigkeit <br><br>möchte damit (wollte damit) nicht sagen das eine Class 10 'mist' ist oder nichts taugt<br>ich persönlich hätt mir die zusätzliche ausgabe sparen können<br><br>MfG Heiko<br><br>> On Sun, 10 Feb 2013 16:09:27 +0100<br>> Thorben Thuermer <r00t@constancy.org> wrote:<br>> > On Sun, 10 Feb 2013 15:18:37 +0100<br>> > "Heiko W." <luckyheiko@hotmail.com> wrote:<br>> > > hab ja seit gestern den Zähler nun so am laufen wie ich das gerne hätte .. <br>> > > auch die ganze Nacht ohne Probleme geloggt usw .. <br>> > > <br>> > > nun hab ich heute morgen das 'frontend' aufgerufen .. <br>> > > und siehe da, genau ab da, keine Daten mehr geloggt .. <br>> > <br>> > das scheint dem merkwuerdigen problem aus<br>> > "[vz-users] frontend tot nach refresh button in IE oder FF"<br>> > http://volkszaehler.org/pipermail/volkszaehler-users/2013-February/001418.html<br>> > aehnlich zu sein...<br>> > vielleicht kommen wir dem hier mal naeher...<br>> <br>> so, wo ich jetzt zugriff auf deinen system habe zeigt sich, dass<br>> das der arme rechnerchen wohl etwas ueberfordert ist...<br>> <br>> jedesmal wenn die daten eines kanals mit der 4h-standardansicht geladen werden,<br>> laeuft eine derartige anfrage:<br>> mysql> SELECT timestamp, value, 1 AS count FROM data WHERE channel_id='28' AND timestamp >= '1360490872286';<br>> 58523 rows in set (48.83 sec)<br>> <br>> und wenn dann noch das frontend kommt, und die daten deiner _acht_ kanaele<br>> _gleichzeitig_ laden will, wird's arg langsam...<br>> ... aber doch irgendwann fertig...<br>> <br>> aber in der zwischenzeit koennen die anfragen von vzlogger nicht<br>> beantwortet werden, wohl weil die anzahl der php-prozesse auf 4 begrenzt ist,<br>> und danach beantwortet der webserver die anfragen dann nichtmehr:<br>> <br>>
[pid 4113] send(12, "POST
/middleware.php/data/04456200-713d-11e2-9b56-234cc60a13ef.json
HTTP/1.1\r\nHost: localhost\r\nContent-type: application/json\r\nAccept:
application/json\r\nUser-Agent: vzlogger/0.3.3 (libcurl/7.26.0
OpenSSL/1.0.1c zlib/1.2.7 libidn/1.25 libssh2/1.4.1
librtmp/2.3)\r\nContent-Length: 162\r\n\r\n[ [ 1360579446054.120117,
-3791.400000 ], [ 1360579447429.320068, -3803.300000 ], [
1360579448920.097168, -3791.100000 ], [ 1360579450179.183105,
-3801.200000 ] ]", 447, MSG_NOSIGNAL) = 447<br>> [pid 4112] recv(11,
"HTTP/1.1 200 OK\r\nX-Powered-By: PHP/5.4.4-12\r\nContent-type:
application/json\r\nTransfer-Encoding: chunked\r\nDate: Mon, 11 Feb 2013
10:44:11 GMT\r\nServer:
lighttpd/1.4.31\r\n\r\n11\r\n{\"version\":\"0.2\"}\r\n0\r\n\r\n", 16384,
0) = 197<br>> <br>> das war der letzte verarbeitete request...<br>> <br>>
[pid 4112] send(11, "POST
/middleware.php/data/0e2c3850-713d-11e2-a384-4bda743e342c.json
HTTP/1.1\r\nHost: localhost\r\nContent-type: application/json\r\nAccept:
application/json\r\nUser-Agent: vzlogger/0.3.3 (libcurl/7.26.0
OpenSSL/1.0.1c zlib/1.2.7 libidn/1.25 libssh2/1.4.1
librtmp/2.3)\r\nContent-Length: 170\r\n\r\n[ [ 1360579446046.865967,
1365814.300000 ], [ 1360579447422.274170, 1365815.800000 ], [
1360579448914.128174, 1365817.300000 ], [ 1360579450174.973877,
1365818.800000 ] ]", 455, MSG_NOSIGNAL) = 455<br>> [pid 4107]
send(7, "POST
/middleware.php/data/ebdae520-713c-11e2-84eb-c1884cb92d66.json
HTTP/1.1\r\nHost: localhost\r\nContent-type: application/json\r\nAccept:
application/json\r\nUser-Agent: vzlogger/0.3.3 (libcurl/7.26.0
OpenSSL/1.0.1c zlib/1.2.7 libidn/1.25 libssh2/1.4.1
librtmp/2.3)\r\nContent-Length: 42\r\n\r\n[ [ 1360579448026.369141,
-2954.700000 ] ]", 326, MSG_NOSIGNAL) = 326<br>> <br>> hier haengt's dann fuer eine weile,<br>> weil die erlaubten php-prozesse alle mit frontend-requests beschaeftigt<br>> sind, und auf daten von der datenbank warten...<br>> <br>>
[pid 4110] recv(9, "HTTP/1.1 200 OK\r\nX-Powered-By:
PHP/5.4.4-12\r\nContent-type: application/json\r\nTransfer-Encoding:
chunked\r\nDate: Mon, 11 Feb 2013 10:45:43 GMT\r\nServer:
lighttpd/1.4.31\r\n\r\n11\r\n{\"version\":\"0.2\"}\r\n0\r\n\r\n", 16384,
0) = 197<br>> [pid 4110] write(3, "[Feb 11 11:45:44][ch3] CURL:
HTTP 1.1 or later with persistent connection, pipelining supported\n",
97) = 97<br>> [pid 4110] send(9, "POST
/middleware.php/data/ddfea5f0-713c-11e2-8667-8d4b408bc4f7.json
HTTP/1.1\r\nHost: localhost\r\nContent-type: application/json\r\nAccept:
application/json\r\nUser-Agent: vzlogger/0.3.3 (libcurl/7.26.0
OpenSSL/1.0.1c zlib/1.2.7 libidn/1.25 libssh2/1.4.1
librtmp/2.3)\r\nContent-Length: 2093\r\nExpect: 100-continue\r\n\r\n",
308, MSG_NOSIGNAL) = 308<br>> [pid 4110] recv(9, "HTTP/1.1 417
Expectation Failed\r\nContent-Type: text/html\r\nContent-Length:
363\r\nConnection: close\r\nDate: Mon, 11 Feb 2013 10:45:44
GMT\r\nServer: lighttpd/1.4.31\r\n\r\n<?xml version=\"1.0\"
encoding=\"iso-8859-1\"?>\n<!DOCTYPE html PUBLIC \"-//W3C//DTD
XHTML 1.0 Transitional//EN\"\n
\"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n<html
xmlns=\"http://www.w3.org/1999/xhtml\" xml:lang=\"en\"
lang=\"en\">\n <head>\n <title>417 - Expectation
Failed</title>\n </head>\n <body>\n <h1>417 -
Expectation Failed</h1>\n </body>\n</html>\n", 16384,
0) = 525<br>> <br>> und jetzt faengt libcurl aus irgendeinem grund an, mit requests "Expect: 100"<br>> header zu senden, wohl weil die requests wegen den<br>> in der "pause" angefallenen daten groesser ausfallen als sonst...<br>> <br>> was lighthttpd dann wohl nicht unterstuetzt...<br>> das problem ist wohl bekannt:<br>> http://www.google.com/search?q=lighthttpd+expect+header<br>> http://redmine.lighttpd.net/issues/1017<br>> <br>> als WORKAROUND habe ich mal in vzlogger code eingebaut,<br>> der curl die verwendung von Expect: verbietet:<br>> http://curl.haxx.se/libcurl/c/curl_easy_setopt.html<br>> <br>> root@raspberrypi:~/vzlogger# git diff src/api.c<br>> diff --git a/src/api.c b/src/api.c<br>> index 9515e49..2ac0055 100644<br>> --- a/src/api.c<br>> +++ b/src/api.c<br>> @@ -119,6 +119,9 @@ int api_init(channel_t *ch, api_handle_t *api) {<br>> api->headers = curl_slist_append(api->headers, "Accept: application/json");<br>> api->headers = curl_slist_append(api->headers, agent);<br>> <br>> + // WORKAROUND for lighthttp not supporting Expect: properly<br>> + api->headers = curl_slist_append(api->headers, "Expect: ");<br>> +<br>> api->curl = curl_easy_init();<br>> if (!api->curl) {<br>> return EXIT_FAILURE;<br>> <br>> <br>> damit funktioniert vzlogger dann nach der durch den frontend-reload verursachten<br>> zwangspause anstandslos weiter.<br>> <br>> - Thorben<br>Mit freundlichen Grüßen<br>Heiko W.<br><br><br><div><div id="SkyDrivePlaceholder"></div><hr id="stopSpelling">From: pp@macpat.de<br>Date: Sun, 17 Feb 2013 12:18:40 +0100<br>To: volkszaehler-users@lists.volkszaehler.org<br>Subject: Re: [vz-users] Problem Middleware ??!!<br><br><br><div><div>Am 17.02.2013 um 11:57 schrieb Heiko W. <<a href="mailto:luckyheiko@hotmail.com">luckyheiko@hotmail.com</a>>:</div><br class="ecxApple-interchange-newline"><blockquote><div class="ecxhmmessage" style="font-size:medium;font-family:Tahoma;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;orphans:2;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;widows:2;word-spacing:0px"><div dir="ltr">meine persönliche Meinung .. lasst die Class 4 drinnen :(<span class="ecxApple-converted-space"> </span><br></div></div></blockquote><br></div><div>das sind immer so Aussagen</div><div>und nicht nur Aussagen, sondern Handlungsempfehlungen</div><div>beschreibe doch einfach deinen subjektiven fall und lass andere werten, oder eben nicht</div><div><br></div><div>bei mir jedenfalls ist der Unterschied von class4 auf class10 schlichtweg nur gefühlt schon exorbitant</div></div> </div></body>
</html>