Short-Polling vs. Long-Polling für Echtzeit-Webanwendungen?

73

Ich erstelle eine Echtzeit-Webanwendung Soweit ich weiß, sind Short-Polling und Long-Polling die beliebtesten Optionen. Welche Vor- und Nachteile kann es geben, wenn man übereinander misst?

javascript  http  comet  real-time  long-polling 
— Jeff
quelle
6
@metrobalderas Langes Poling ist hier, nur nicht als Websockets. Sie können weiterhin einen iframe / script / xhr verwenden und verhindern, dass der Server die Verbindung schließt.
— Hemlock
@metrobalderas: Google "Ajax Comet"
— Slebetman
3
Für alle anderen, die sich mit diesem Thema befassen, ist hier eine weitere Frage zum Thema Kurzumfrage und Langumfrage .
— Blong

Antworten:

70

  • Kurzes Polling (auch bekannt als AJAX-basierter Timer):

    Vorteile: einfacher, nicht serveraufwendig (wenn die Zeit zwischen den Anforderungen lang ist).
    Nachteile: schlecht, wenn Sie benachrichtigt werden müssen, wenn das Serverereignis ohne Verzögerung auftritt. Beispiel ( ItsNat basiert)

  • Lange Umfragen (auch bekannt als Comet basierend auf XHR)

    Vorteile: Sie werden benachrichtigt, wenn das Serverereignis ohne Verzögerung auftritt. Nachteile: komplexere und mehr verwendete Serverressourcen. Beispiel (ItsNat basiert)

— jmarranz
quelle
25
Speziell für lange Abfragen ist die maximale Anzahl offener Sockets die wichtigste einschränkende Serverressource. Unterschiedliche Betriebssysteme haben unterschiedliche Grenzen, aber es gibt Grenzen und die Grenzen sind viel niedriger als der verfügbare Speicher. Kurze Abfragen umgehen dies, da jede Verbindung nur für einen kurzen Zeitraum geöffnet ist und daher viele Verbindungen zeitmultiplexiert werden können.
— Slebetman
Lange Abfragen verbrauchen nicht mehr Ressourcen, sondern viel weniger. Eine Leerlauf-Socket-Verbindung verwendet grundsätzlich keine anderen Ressourcen als Keep-Alive-Pakete (falls aktiviert / konfiguriert) und einen offenen Dateideskriptor.
— Nepoxx
83

Nur aus Gründen der Argumentation.

Beide sind http-Anfragen (xhr), und es ist zumindest teilweise falsch, dass mehr Serverressourcen verwendet werden (hängt vollständig von der Technologie ab, wird später erklärt).

Kurze Abstimmung.

Viele Anfragen, die verarbeitet werden, wenn sie auf den Server kommen. Erzeugt viel Verkehr (verwendet Ressourcen, gibt sie jedoch frei, sobald die Antwort zurückgesendet wird):

00:00:00 C-> Is the cake ready? 
00:00:01 S-> No, wait.
00:00:01 C-> Is the cake ready?
00:00:02 S-> No, wait.
00:00:02 C-> Is the cake ready? 
00:00:03 S-> Yes. Have some lad.
00:00:03 C-> Is the other cake ready? ..

Lange Umfrage

Eine Anfrage geht an den Server und der Client wartet auf die Antwort (ungelöst). Im Falle eines Servers mit PHP / Apache würde dies bedeuten, dass ein erzeugter Thread behandelt wird, der Ressourcen reserviert, bis er fertig ist. Der Datenverkehr ist also geringer, aber Sie verbrauchen Ihre Ressourcen schnell (oder blockieren Ressourcen). Wenn Sie jedoch beispielsweise Node (oder einen anderen asynchronen Ansatz - z. B. c ++ qt) verwenden, können Sie möglicherweise die Ressourcennutzung erheblich minimieren (Antwortobjekt für http-Anforderung speichern und verwenden, wenn die Arbeit fertig ist).

12:00 00:00:00 C-> Is the cake ready? 
12:00 00:00:03 S-> Yes.Have some lad.
12:00 00:00:03 C-> Is the cake ready?

Wenn Sie dies mit einer kurzen Abfrage vergleichen, werden Sie feststellen, dass Sie möglicherweise in einer kurzen Abfrage mehr Übertragung verwendet haben, aber während dieser 3 Sekunden benötigen Sie tatsächlich 1,5 Sekunden Verarbeitungszeit (was bedeutet, dass zwischen Ihren Anrufen etwas ausgeführt werden könnte). Für lange Abstimmungen wurden immer die gleichen Ressourcen verwendet. Normalerweise beginnt PHP mit allen Bibliotheken mit 4 MB Speicher - dann haben Sie ein Framework von 4 bis 20 MB. Angenommen, Sie haben 1024 MB RAM zur Verfügung (kostenlos). Nehmen wir an, wir sind pessimistisch und gehen davon aus, dass Sie 25 MB pro PHP-Instace verwenden. Dies bedeutet, dass Sie nur bis zu 40 lange abgefragte Verbindungsskripte erhalten können.

Dies ist genau der Grund, warum Sie mit Node möglicherweise viel mehr Dienste leisten können, da der Knoten seine Instanzen nicht erzeugt (es sei denn, Sie möchten Worker usw. verwenden), sodass Sie mit demselben Speicher wahrscheinlich problemlos zu 10.000 hängenden Verbindungen gelangen können. Sie würden eine Spitze in der CPU bekommen, wenn sie kommen und wenn sie möglicherweise freigegeben werden, aber wenn sie im Leerlauf sind, ist es so, als wären sie nicht da (Sie zahlen nur für die Speicherstrukturen, die Sie in Node / C ++ behalten würden).

Websocket

Wenn Sie nun einige Dinge senden möchten, wann immer sie sich im oder außerhalb des Clients befinden, wählen Sie die Websockets (ws-Protokoll). Der erste Aufruf entspricht der Größe der http-Anforderung. Später senden Sie jedoch nur die Nachrichten von Client zu Server (neue Fragen) und von Server zu Client (Antworten oder Pushs - können sogar Broadcasts für alle verbundenen Clients ausführen). Es gibt PHP-Websocekts-Bibliotheken, aber verwenden Sie auch hier eine andere Technologie - vorzugsweise Node oder C ++.

Einige Bibliotheken, wie z. B. socket.io, haben eine eigene Hierarchie. Wenn das Websocket ausfällt, wird auf lange oder kurze Abfragen zurückgegriffen.

Wann zu verwenden.

Kurze Umfrage - na ja, niemals ^^.

Lange Abfrage - möglicherweise, wenn Sie einen einzelnen Anruf mit dem Server austauschen und der Server im Hintergrund arbeitet. Auch wenn Sie den Server nicht mehr auf derselben Seite abfragen. Auch wenn Sie PHP nicht als Layer verwenden, um die lange abgefragte Verbindung zu handhaben (Node / C ++ kann eine einfache mittlere Layer sein). Beachten Sie, dass lange Abfragen sehr nützlich sein können, aber nur, wenn Sie es so machen.

Websocket - Möglicherweise tauschen Sie mehr als ein oder zwei Anrufe mit dem Server aus, oder es kommt etwas von einem Server, den Sie nicht erwartet / gefragt haben, z. B. eine Benachrichtigung über E-Mails oder ähnliches. Sie sollten verschiedene "Räume" planen, abhängig von den Funktionen. Umfassen Sie die ereignisbasierte Natur von Javascript;]

— sp3c1
quelle
3
Long-Polling ist also im Wesentlichen eine dauerhafte Verbindung, die ein asynchroner offener Socket sein kann, während Short-Polling normalerweise ewige Anforderungen eines synchronen Prozesses sind.
— Joseph Persie
1
Es ist als solches nicht beständig - es ist so, dass Sie keine Antwort senden, die vom Server erwartet wird - und sobald Sie es schließen - mit anderen Worten, es wartet (hängt). Das gleiche Verhalten wie bei einigen langen Cron-Skripten - das sendet nur Daten, wenn es nach 10 Minuten zum Browser bereit ist. Das Prinzip ist das gleiche - seine gerechte Verwendung ändert sich. Es ist also sehr synchron. Dies bringt Sie auch zu dem zweiten Problem mit langen Abfragen, das ich nicht erwähnt habe - Browser-Einschränkungen für die Anzahl offener Verbindungen (ich denke, es sind ungefähr 8 - es gibt keine Begrenzung für Websocket-Verbindungen atm in Browsern).
— SP3C1
2
Eine weitere schwerwiegende Einschränkung bei langen Abfragen ist das Sperren von Sitzungen. Wenn Sie die Sitzung nicht schließen oder den nicht blockierenden Sitzungsmanager (wie z. B. db) verwenden, wird die Sitzungsdatei für den Benutzer gesperrt und akzeptiert keine Anforderungen des Benutzers, auch nicht von einem anderen Browser Fenster.
— 14.
3
Kurze Abfragen haben ihren Platz, beispielsweise in Dashboard-Anwendungen, aufgrund der Architektur- und UX-Vorteile des Stapelns von UI-Updates.
— Nicodjimenez
1

Wenn Sie eine Echtzeitanwendung basierend auf einer Datenbank erhalten möchten, können Sie eine Kombination aus Ajax Long Poll und Comet verwenden. Lange Umfragen sind sehr gut für Ihre Bandbreite und auch sehr nützlich für Benutzer-MB. Denn wenn Benutzer eine Anfrage senden, zahlt der Benutzer dafür wie MB oder eine Art Internetverbindung. Zum Beispiel für kurze Umfragen, wenn Sie so etwas wie eine Anfrage per senden Die Internetnutzung des zweiten Benutzers ist höher, da jeder Verbindungsbenutzer dafür bezahlt (dies bedeutet, dass der Benutzer Mb verliert), aber in der langen Abfrage zahlt der Benutzer nur für neue Nachrichten.

Websocket ist wirklich eine gute Sache, aber wenn Sie es verwenden, sollten Sie über ein großes Problem nachdenken, dass viele Leute das Chat-System nicht verwenden können, da Websocket nur für eine neue Version von Browsern gedacht ist

— Ibrahim Hasanov
quelle
Viele Leute sollten ihre Browser aktualisieren ... Websockets wurden bereits in IE11 unterstützt. Microsoft drängt alle auf Windows 10, und das bedeutet standardmäßig Edge. Es sei denn, Sie verwenden Opera Mini, aber dann ist das Ihre Schuld: P
— Manatax
1
und deshalb sollten Sie so etwas wie socket.io verwenden, das dies für Sie erledigt, wenn keine Websockets verfügbar sind;], aber die Codebasis bleibt gleich
— sp3c1
@ sp3c1 Socket.io ist ein Albtraum der Skalierbarkeit.
— Hobbyist
@Hobbyist wie so? Sie können den Lastausgleich durchführen und jetzt den Socket auch für verschiedene Prozesse freigeben. Sie können jederzeit auf die reine Websocket-Implementierung zurückgreifen, aber der Kern bleibt gleich. Sie können die Socket-Implementierung selbst durchführen, aber warum das Rad erfinden, wenn es für webdev ein guter Standard ist? Wenn Sie Probleme mit der verteilten Kommunikation der Prozesse haben, die Socket-Verbindungen verarbeiten, können Sie jederzeit den Redis Pub / Sub erkunden. Der wahre Vorteil von socket.io gegenüber websocket ist das Fallback-Protokoll, das es für alte Browser vaibale macht.
— SP3C1
@ sp3c1 Ich bin froh zu hören, dass ich socket.io in Shared Hosting verwenden kann? Weil Websocket auch den Nachteil hat, dass es nicht an Shared Hosting-Plänen funktioniert
— Ibrahim Hasanov
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.