Re: [vz-dev] jsonp support für vz

2013-04-07 Diskussionsfäden Andreas Goetz

Hallo Jakob,

danke für den Hinweis! padding=? funktioniert tatsächlich auch (hatte 
ich in der Doku anders verstanden)- damit ist alles Paletti, danke! 
Jetzt fehlt nur noch ein eleganter weg, zusätzliche MWs in der 
Konfiguration anzugeben.


Viele Grüsse,
Andreas

On 07.04.2013 02:33, Jakob Hirsch wrote:

On 04.04.2013 19:14, Andreas Goetz wrote:

Das hab ich glatt übersehen :/, content-type ist definition falsch. Ich
fände dennoch callback statt padding als Parameter schöner- dann
liesse sich nämlich auch jQuery getJSON nutzen. Mit der jetzigen Lösung

Wenn ich die Beschreibung von getJSON richtig verstanden habe (es ist
leider nicht explizit beschrieben), funktioniert das mit jedem
Parameter, der vor =? steht, in unserem Fall also padding=?.
Ich finde padding als Parametername auch nicht so prall (auch wenn es
technisch korrekt ist), aber ohne Not ändert man sowas nicht.


muss man zwangsweise auf $.ajax ausweichen um die notwendigen Parameter
reinzufummeln. Aber ja- es ist möglich ;)

Also der Unterschied zwischen
$.getJSON(url, data, success)
und
   $.ajax({dataType: json, url: url, data: data, success: success});
ist jetzt nicht soo riesig...





Re: [vz-dev] Alternative Implementierung für vzcompress

2013-04-07 Diskussionsfäden Daniel Lauckner
Abend,

Florian

Auch von mir ein herzliches Dankeschön für das Script.


Am Samstag, 6. April 2013 um 20:54 schrieb Bernd Gewehr:
 Ich überlege, ob mir eine Optimierung einfällt, um die redundante
 Bearbeitung der alten Daten immer und immer wieder zu umgehen:

Mir ist aufgefallen das das Script beim Zeitraum immer die selben
Sekunden (26 bei 1 Minute, 47 bei 5) anzeigt.
Wenn der verbleibende Datensatz auf dieser Sekunde liegt müsste man
damit doch auch Arbeiten können?

 Ein logfile ist in php möglicherweise am einfachsten, oder?
 /var/log/vzcompress.log könnten alle Ergebnisse und die letzte ID oder das
 letzte timestamp/Channel_id-Pärchen enthalten. Wenn man sie löscht, dann
 geht's von vorne los...

Oder so. Einfach in der Handhabung und ressourcenschonend.

 Das spart Zeit und CPU-Last, denn mein vzlogger steigt regelmäßig aus, wenn
 der vzcompress Cronjob losrennt.

Ich hatte vzlogger immer vorher beendet weil ich eh damit
gerechnet habe das er abschmiert.


mfg Daniel




Re: [vz-dev] Alternative Implementierung für vzcompress

2013-04-07 Diskussionsfäden f . knodt

Nabend,

Am 2013-04-07 22:46, schrieb Daniel Lauckner:

Mir ist aufgefallen das das Script beim Zeitraum immer die selben
Sekunden (26 bei 1 Minute, 47 bei 5) anzeigt.


Wenn das Script etwas zusammenfasst basiert Datum/Zeit auf der 
Startzeit, ist also nicht zwingend konstant. Es ist allerdings auch 
schon eine Optimierung in der Art drin: Das Script überspringt das 
Zusammenfassen (=UPDATE) wenn im Zeitraum nur ein Datensatz vorhanden 
ist. Übrig bleiben dann bei schon bearbeiteten Bereichen nur die 
lesenden Datenbankabfragen (SELECT), also im Prinzip das selbe wie eine 
Abfrage auf Basis der Uhrzeit. Ein Logfile mit den letzten Timestamps 
wäre schneller als die ganzen SELECT-Abfragen, allerdings verliert man 
so auch etwas Flexibilität - über die API ist es möglich Daten mit 
älteren Timestamps einzufügen (nutze ich z.B. für einige Sensoren, 
welche nur alle x Stunden synchronisiert werden oder offline laufen und 
manuell importiert werden), die würden dann nicht verarbeitet.


Das spart Zeit und CPU-Last, denn mein vzlogger steigt regelmäßig 
aus, wenn

der vzcompress Cronjob losrennt.

Ich hatte vzlogger immer vorher beendet weil ich eh damit
gerechnet habe das er abschmiert.


Nunja, eigentlich sollte er das nicht tun - die meiste Arbeit sind 
vermutlich die SELECT-Abfragen zum zusammenfassen, dabei dürfte MySQL 
aber keinen LOCK o.Ä. versuchen. Was ich mir nur vorstellen kann wäre, 
dass der DB-Server je nach Hardware ins Stocken kommt und vzlogger in 
einen Timeout läuft. Generell sehe ich jedenfalls kein Problem - auf 
meinem E450 gehen während das Script läuft keine neuen Daten verloren, 
allerdings nutze ich nur direkte HTTP-Requests, und nicht den vzlogger. 
Eventuell könnte ein usleep/sleep nach dem UPDATE oder gar SELECT helfen 
die Last zu reduzieren - wenn das Script per cron o.Ä. läuft lässt sich 
der Geschwindigkeitsverlust sicher verschmerzen.


Am 2013-04-06 20:54, schrieb Bernd Gewehr:

Wann wird das file im VZ-git sichtbar?
Ist noch nicht eingeschickt, ich wollte es erst etwas abhängen 
lassen, sodass die gröbsten Fehler vorher raus sind


Florian


Re: [vz-dev] jsonp support für vz

2013-04-07 Diskussionsfäden Jakob Hirsch
On 07.04.2013 13:23, Andreas Goetz wrote:
 Jetzt fehlt nur noch ein eleganter weg, zusätzliche MWs in der
 Konfiguration anzugeben.

In der Konfiguration von was?