Client Benachrichtigung, sollte ich einen AJAX Push oder Poll verwenden?

Question

Ich arbeite an einem einfachen Benachrichtigungsdienst, der verwendet wird, um Nachrichten an die Benutzer zu senden, die auf einer Website surfen. Die Benachrichtigungen müssen nicht in Echtzeit gesendet werden, aber es könnte eine bessere Benutzererfahrung sein, wenn sie häufiger auftreten als alle 5 Minuten. Die Daten, die zu und von dem Client gesendet werden, sind nicht sehr groß, und es ist eine einfache Datenbankabfrage, um die Daten abzurufen.

Beim Lesen anderer Konversationen zu diesem Thema scheint es, dass ein AJAX-Push zu höheren Serverlasten führen kann. Da ich längere Serververzögerungen tolerieren kann, lohnt es sich, wenn der Server Push-Benachrichtigungen sendet oder einfach abfragt.

Es ist nicht viel schwieriger, das Push-Szenario zu implementieren und so dachte ich, ich würde sehen, was die Meinung hier war.

Danke für Ihre Hilfe.

EDIT: Ich habe in einen einfachen AJAX Push geschaut und eine einfache Demo basierend auf diesem article von Mike Purvis implementiert. Die Client-Last ist ziemlich niedrig bei ungefähr 5k für die anfängliche Version und es wird erwartet, dass dies für eine lange Zeit so bleibt.

---

Vielen Dank für Ihre Antworten. Ich habe mich entschieden, mit der Polling-Lösung zu gehen, aber alles in eine Utility-Bibliothek zu packen, so dass es einfacher ist, sie später zu ändern.

Answer 1

Da die Verwendung eines Push-Vorgangs eine offene HTTP-Verbindung zwischen Ihrem Server und jedem Client erfordert, würde ich auch zur Umfrage gehen - das wird nicht nur eine Menge Serverressourcen verbrauchen, sondern es wird auch sein wesentlich schwieriger zu implementieren als matt b erwähnt.

Meine Erfahrung mit dem Polling ist, dass, wenn Sie ein ausreichend häufiges Polling-Intervall auf einer ausreichend ausgelasteten Website haben, Ihre Web-Server-Logs schnell mit Poll-Anfragen überschwemmt werden können.

Bearbeiten (2017): Ich würde sagen, Ihre Entscheidungen sind jetzt zwischen WebSockets und lange Abfragen (in einer anderen Antwort erwähnt). Sounds wie Long Polling könnte die richtige Wahl sein, basierend auf der Art, wie die Frage erwähnt, dass die Benachrichtigungen nicht in Echtzeit empfangen werden müssen, eine unregelmäßige Umfragezeit wäre ziemlich einfach zu implementieren und sollte auf Ihrem Server nicht sehr anstrengend sein . Websockets sind cool und eine gute Wahl für viele Anwendungen in diesen Tagen, Sounds wie das könnte in diesem Fall jedoch übertrieben sein.

Answer 2

Ich würde eine Umfrage implementieren, nur weil es einfacher zu schreiben klingt, und es einfach zu halten ist sehr wertvoll.

Answer 3

Nicht sicher, wenn Sie sich einige der COMET-Implementierungen dort draußen angesehen haben (ist das, was Sie mit AJAX zu tun haben).

Wenn der Benutzer auf der Website surft, fragt er dann nicht nach Informationen vom Server, auf die diese Benachrichtigung übertragen werden kann?

Answer 4

Ich habe es selbst nicht versucht, aber manche sagen COMET works and is easier than you think. Es gibt auch ein Ruby on Rails-Plug-in mit der Bezeichnung Juggernaut, von dem ich gehört habe, dass es sehr hoch ist. Noch einmal, ich habe es nicht benutzt, also YMMV, aber mein Verständnis ist, dass es viel weniger Ressourcen im Vergleich zum Polling benötigt. Ich glaube (kann jemand bestätigen?), Dass COMET MacRumorsLive.com Live Blogging von WWDC Stevenotes liefert.

Answer 5

Es ist unmöglich zu sagen, ob das Polling teurer ist als das Drücken, ohne zu wissen, wie viele Clients Sie haben werden.Ich würde empfehlen, abzufragen, weil:

Es klingt, als ob Sie Daten etwa einmal pro Minute aktualisieren möchten. Wenn Benachrichtigungen nicht viel schneller ankommen können, bedeutet Push, dass Sie eine HTTP-Verbindung offen halten, aber wenig Aktivität sehen.

Das Polling basiert auf den bestehenden HTTP-Konventionen. Daher ist jeder Server, der mit Webbrowsern kommuniziert, bereits bereit, auf normale Ajax-Anfragen zu reagieren. Eine Comet- oder Flash-Socket-basierte Lösung hat andere Anforderungen. Sie benötigen etwas wie cometd auf der Serverseite und eine clientseitige Bibliothek, die serverseitig anstößt.

Also, wenn Sie etwas Schwerlast benötigen, um einen Strom von Daten und einen Haufen Kunden zu verwalten, würde ich Comet empfehlen. Aber das scheint nicht der Fall zu sein.

Answer 6

Beide haben unterschiedliche Anforderungen und adressieren unterschiedliche Szenarien.

Wenn Sie Echtzeit-Updates benötigen, wie in einem Online-Chat, Push ist ein Muss.

Aber, wenn die Refresh-Periode ist groß, wie es in Ihrem Fall ist (5 Minuten), dann Pool ist die geeignete Lösung. Push erfordert in diesem Fall eine Menge Ressourcen sowohl vom Client als auch vom Server.

Tipp! versuchen, die Seite, die den Pool schnell und sauber überprüft, so dass es nicht viel Ressourcen auf dem Server in jeder Anforderung verbraucht. Was ich normalerweise mache, ist eine Flagge im Gedächtnis zu behalten (wie in einer Sitzungsvariablen), die sagt, wenn der Pool leer ist oder nicht ... also schaue ich nur in den Pool, wenn er nicht leer ist. Wenn der Pool die meiste Zeit leer ist, wird die Seitenanforderung extrem schnell ausgeführt.

Answer 7

Auf jeden Fall drücken Sie es viel kühler. Wenn Sie nur einfache Benachrichtigungen möchten, würde ich etwas wie StreamHub Push Server verwenden, um die Schwerarbeit für Sie zu tun. Die Entwicklung Ihrer eigenen Ajax Push-Funktionalität ist ein extrem schwieriger und steiniger Weg - Sie müssen es in allen Browsern funktionieren lassen und dann mit Firewalls und Proxies umgehen, Keep-Alive-Verbindungen zerstören usw. ... Warum das Rad neu erfinden? Außerdem hat es eine ähnlich niedrige Grundfläche von weniger als 10K, also sollte es passen, wenn das eine Priorität für Sie ist.

Answer 8

Es gibt jetzt einen Service http://pusherapp.com, der versucht, dieses Problem ein für alle Mal im Handumdrehen zu lösen. Könnte es wert sein, auschecken. (Disclaimer: ich bin in keiner Weise mit ihnen verbunden).

Answer 9

Ich bin überrascht, dass hier niemand lange polling erwähnt hat. Lange Polling bedeutet eine offene Verbindung für einen längeren Zeitraum (sagen 30-60 Sekunden) zu halten, und wenn es einmal geschlossen ist, öffne es wieder und lasse einfach den Socket/die Verbindung auf Antworten warten. Dies führt zu weniger Verbindungen (aber längeren) und bedeutet, dass die Antworten fast unmittelbar sind (einige müssen möglicherweise auf eine neue Abrufverbindung warten). Ich möchte hinzufügen, dass dies in Kombination mit Technologien wie NodeJS zu einer sehr effizienten und ressourcenschonenden Lösung führt, die zu 100% browserkompatibel für alle gängigen Browser und Versionen ist und keine zusätzlichen Technologien wie Comet oder Blitz.

Ich weiß, das eine alte Frage, aber dachte, es immer noch nützlich sein könnte, diese Informationen zu liefern :)