streamt eine praktikable Option? gibt es einen Leistungsunterschied auf dem Server Ende je nachdem, welche ich wählen? ist einer besser als der andere für diesen Fall?lange Abfrage vs Streaming für ca. 1 Update/Sekunde
Ich arbeite an einer GWT-Anwendung mit Tomcat läuft auf dem Server-Ende. Um meine Bedürfnisse zu verstehen, stellen Sie sich vor, die Aktienkurse mehrerer Aktien gleichzeitig zu aktualisieren.
Möchten Sie, dass der Prozess Client- oder Server-gesteuert wird? Mit anderen Worten: Möchten Sie neue Daten an die Clients senden, sobald sie verfügbar sind, oder möchten Sie, dass die Clients neue Daten anfordern, wenn sie dies für richtig halten, obwohl dies möglicherweise nicht einmal pro Sekunde erfolgt? Was ist die Wahrscheinlichkeit, dass der Kunde in der Lage sein wird, auf eine Antwort zu warten? Auch wenn Sie erwarten, dass die Ereignisse einmal pro Sekunde auftreten, wie lange dauert es zwischen einer Anforderung von einem Client und der Rückkehr vom Server? Wenn es länger als eine Sekunde dauert, würde ich erwarten, dass Sie sich darauf konzentrieren, die Ereignisse an die Kunden zu schicken, obwohl ich umgekehrt erwarten würde, dass die Abstimmung in Ordnung ist. Wenn die Antwort länger als das Intervall dauert, streamen Sie im Grunde trotzdem, da ein neues Ereignis bereitsteht, wenn der Client das letzte empfängt, sodass der Client im Wesentlichen ständig abfragen und immer Ereignisse empfangen kann - in diesem Fall Streaming Die Daten wären tatsächlich leichter, da Sie den Verbindungs-/Verhandlungsaufwand aus dem Prozess entfernen.
Ich würde vermuten, dass die Serverlast für ein Client-basiertes (Pull-) Abonnement höher ist als für eine Streaming-Konfiguration, da der Client die Verbindung jedes Mal neu verhandeln muss, anstatt eine Verbindung offen zu lassen. Jede offene Verbindung in einem Streaming-Modell würde jedoch auch Serverressourcen erfordern. Es hängt davon ab, wie der Kompromiss zwischen der Aggressivität Ihres Verhandlungsprozesses und der Menge an Speicher/Verarbeitung ist, die für jede offene Verbindung erforderlich ist. Ich bin jedoch kein Experte, also kann es andere Faktoren geben.
UPDATE: This guy spricht über die Kompromisse zwischen Long-Polling und Streaming, und er scheint zu sagen, dass mit HTTP/1.1 der Verbindung Neuverhandlung ist trivial, so dass das nicht so ein Problem ist.
Sicher, wenn Sie Daten pushen möchten, scheint Streaming eine bessere Leistung zu bieten, wenn Ihr Server die erwartete Anzahl von kontinuierlichen Verbindungen bewältigen kann. Aber es gibt ein anderes Problem, das Sie nicht ansprechen: Sind Sie Internet oder Intranet? Es wurde berichtet, dass Streaming Proxies Probleme verursacht, so wie Sie es erwarten würden. Für eine allgemeine Lösung wäre es wahrscheinlich besser, wenn Sie eine lange Umfrage durchführen würden - für ein Intranet, in dem Sie die Netzwerkinfrastruktur verstehen, ist Streaming wahrscheinlich eine einfachere, bessere Lösung für Sie.
Das Streaming wird schneller, da Daten nur in einer Richtung übertragen werden. Beim Polling beträgt die Latenz mindestens zweimal.
Das Polling ist widerstandsfähiger gegenüber Netzwerkausfällen, da es nicht darauf angewiesen ist, dass eine Verbindung offengehalten wird.
Ich würde nur für die Robustheit polling gehen.
Ich möchte klarstellen, dass meine Frage lange Umfrage und nicht traditionelle Umfrage betrifft. Außerdem sollte NIO selbstverständlich sein. – jcee14
Sie haben recht, NIO bricht den Thread pro Verbindungsbeschränkung ab, wodurch die Thread-Anforderung verringert wird. –
Für Live-Aktienkurse würde ich absolut die Verbindung offen halten, und Benutzer-Alarm/Reconnection beim Trennen sicherstellen.
Die StreamHub GWT Comet Adapter wurde genau für dieses Szenario der Streaming-Aktienkurse entwickelt. Beispiel hier: GWT Streaming Stock Quotes. Es aktualisiert die Aktienkurse mehrerer Aktien gleichzeitig. Ich denke, die Implementierung darunter ist Comet, die im Wesentlichen über HTTP streamt.
Bearbeiten: Es verwendet eine andere Technik für jeden Browser.Um die Website zu zitieren:
Es gibt verschiedene darunter liegende Techniken verwendet Comet zu implementieren einschließlich versteckten iFrame, XMLHttpRequest/Script Lange Polling, und Embedded-Plug-in wie Flash. Die Einführung von HTML 5 WebSockets in künftigen Browsern wird einen alternativen Mechanismus für HTTP Streaming zur Verfügung stellen. StreamHub verwendet einen "best-fit" Ansatz mit der leistungsstärksten und zuverlässige Technik für jeden Browser.
Es ist nicht wirklich wichtig. Der Verbindungsneuverhandlungsaufwand ist bei HTTP1.1 so gering, dass Sie auf die eine oder andere Weise keine wesentlichen Leistungsunterschiede feststellen werden.
Die Vorteile der langfris Polling sind Kompatibilität und Zuverlässigkeit - keine Probleme mit Proxies, Häfen, Erkennung trennt usw.
Die Vorteile von „true“ Streaming möglicherweise Overhead reduziert werden würde, aber wie bereits erwähnt diese Nutzen ist viel, viel weniger als es sein soll.
Persönlich finde ich einen gut entworfenen Komet-Server, um die beste Lösung für eine große Anzahl von Updates und/oder Server-Push zu sein.
Hey rwmnau, der Link, den du zur Verfügung gestellt hast, ist erhellend. Um Ihre Fragen zu beantworten, möchte ich Daten an die Benutzer weitergeben, sobald sie verfügbar sind. – jcee14
Wenn Sie versuchen, Daten so schnell wie möglich an die Benutzer zu senden, dann denke ich, dass die Wahl streamen muss, da dies eine Push-basierte Verbindung aufrechterhält. Mit einem Pull-Setup warten Sie darauf, dass die Kunden fragen, aber mit Push erhalten sie die Daten, sobald Sie sie ihnen geben. Lass mich wissen, was du am Ende kommst und warum! – SqlRyan