AJAX Polling: Eure Meinung zu verschiedenenen Verfahren

[erbsensuppe]

Hi,

in diesem Thread

http://forum.de.selfhtml.org/archiv/2006/4/t127682/

ist schon mal ein Verfahren des Pollings diskutiert worden, das fuer eines meiner Projekte sehr vorteilhaft erscheint.

Kurzer Ueberblick:

Ich habe eine Statusseite, die verschiedene Geraete-Objekte enthaelt, die sich Messdaten aus einer DB holen. Die Seite enthaelt ein AJAX-Polling-Objekt, das permanent nach Statusaenderungen in der DB Ausschau haelt. Existieren Aenderungen, holt das Objekt die Daten ab und reicht sie an die Geraete-Objekte weiter, die dann ihr Aussehen oder die Messdaten aktualisieren.

So weit, so gut, das funktioniert wunderbar.

Es kann allerdings sein, dass zahlreiche Aenderungen auf einmal eintreten und das Polling-Objekt eine Menge zu tun hat. Ich moechte vermeiden, dass eine wesentliche Verzoegerung der Statusinformationen der Geraete auftreten oder das Polling-Objekt nicht hinterher kommt.

Daher meine Frage:

Welches der folgenden Verfahren ist Eurer Meinung nach effizienter oder unproblematischer im Betrieb?

a) IST-ZUSTAND: Das Polling-Objekt holt bei Aenderung die Daten aller betroffenen Geraete vollstaendig ab, die Weiterleitung der Daten geschieht ueber Javascript, die Geraete koennen selbst nicht pollen. Meine Befuerchtung ist, dass das Polling unter hoher Last "Verstopfung" bekommen koennte.

b) Das Polling-Objekt holt nur die IDs der Geraete ab, die eine Statusaenderung aufweisen und informiert die Geraete-Objekte, dass sie ihren Status per AJAX updaten sollen. Hier ist m.E. das Risiko einer Verstopfung geringer und das Verfahren kommt dem traditionellen Observer-Pattern schon etwas naeher. Allerdings sind dazu wiederum mehrere gleichzeitige HTTP-Requests der einzelnen Geraete noetig und ich bin mir nicht sicher, ob das einen erheblichen Performanceverlust darstellen koennte.

Wie ist Eure Meinung und/oder Erfahrung dazu?

Bin fuer jeden Tipp dankbar.

Danke und Gruesse
Martin

[Don P]

Hallo,

Die Sache lässt sich nur schwer generell beurteilen. Es kommt m.E. darauf an, wieviele Statusänderungen pro Zeiteinheit zu erwarten sind. Verzögerungen ergeben sich wohl weniger durch den ausgeführten JavaScript-Code im Polling-Objekt, als vielmehr durch die Menge der nötigen HTTP Requests. Der Flaschenhals ist erfahrungsgemäß die Datenübertragung, jedenfalls wenn das Internet beteiligt ist.

a) IST-ZUSTAND: Das Polling-Objekt holt bei Aenderung die Daten aller betroffenen Geraete vollstaendig ab, die Weiterleitung der Daten geschieht ueber Javascript.

Wenn hier nur ein Request für alle geänderten Zustände erfolgt, scheint mir das ein effizienter Weg.

b) Das Polling-Objekt holt nur die IDs der Geraete ab, die eine Statusaenderung aufweisen und informiert die Geraete-Objekte, dass sie ihren Status per AJAX updaten sollen.

Durch die höhere Zahl einzelner Requests würde ich hier größere Verzögerungen bzw. eher eine Tendenz zur "Verstopfung" erwarten, als bei der Lösung a).
Abhängig von der übertragenen Datenmenge pro Gerät und der Häufigkeit von Aktualisierungen könnte diese Variante in der Praxis trotzdem brauchbarer sein, weil die Geräte-Objekte unabhängiger sind, d.h. sie müssen ggf. nicht alle warten, bis das Polling-Objekt jeweils ein paar GB neuer Daten vollständig empfangen hat.

Gruß, Don P

[erbsensuppe]

Hallo Don,

vielen Dank fuer Deine Antwort. Es ist immer hilfreich, wenn man eine zweite Meinung dazu hat, die einen mal in eine andere Richtung schubst.

Die Daten sind ziemlich schmal (im Wesentlichen Status a la OK, Fault, Unknown, Pending) und dann diverse Messdaten, die aber auch nicht uebermaessig viel Bandbreite kosten. Daher gehe ich davon aus, dass in meinem Fall der Weg ueber das 'Master-Polling' der Bessere sein wird.

Herzliche Gruesse
Martin

[Sven Rautenberg]

Moin!

Die Daten sind ziemlich schmal (im Wesentlichen Status a la OK, Fault, Unknown, Pending) und dann diverse Messdaten, die aber auch nicht uebermaessig viel Bandbreite kosten. Daher gehe ich davon aus, dass in meinem Fall der Weg ueber das 'Master-Polling' der Bessere sein wird.

Zu bedenken ist immer, dass ein Browser nicht beliebig viele parallele Verbindungen zu einem Server aufbaut. Ein Standardwert bei HTTP 1.1 ist 2 (in Worten: zwei). Man schießt sich also selbst ins Bein, wenn man viele parallele Requests abfeuert, die genausogut auch gesammelt in einem Request übertragen werden könnten.

- Sven Rautenberg