長輪詢VS流約1更新/秒

Question

是流一個可行的選擇？ 服務器端的性能差異取決於我選擇哪一個？ 對於這種情況比另一個更好嗎？

我正在使用運行在服務器端的Tomcat的GWT應用程序。爲了理解我的需求，可以想象同時更新多個股票的股票價格。

Answer 1

你想的過程是客戶端或服務器驅動？換句話說，您是否希望在客戶端可用時立即向客戶端推送新數據，或者您是否希望客戶端在他們認爲合適的時候請求新數據，即使這些數據可能不是每秒一次？客戶可以堅持等待答案的可能性是什麼？即使您期望事件每秒發生一次，客戶請求與服務器返回之間需要多長時間？如果時間超過一秒鐘，我希望你傾向於將事件推送給客戶，儘管反過來說，我希望投票可以。如果響應時間比時間間隔長，那麼你本質上是流式傳輸，因爲當客戶端收到最後一個事件時就準備好了一個新事件，所以客戶端可以持續地進行輪詢並總是接收事件 - 在這種情況下，流式傳輸數據實際上會更輕量級，因爲您要從流程中移除連接/協商開銷。

我會懷疑，基於客戶端（拉）訂閱的服務器負載較高，而不是流配置，因爲客戶端每次都必須重新協商連接，而不是斷開連接，但流式模型中的每個開放連接也需要服務器資源。這取決於您的談判過程的積極性與每個開放連接需要多少內存/處理之間的權衡。但我不是專家，所以可能還有其他因素。

更新：This guy談論長輪詢和流媒體之間的權衡，他似乎認爲使用HTTP/1.1，連接重新協商過程是微不足道的，所以這不是一個問題。

Answer 2

當然，如果你正在尋找推數據，流似乎提供更好的性能，如果您的服務器可以處理連續連接的預期數量。但還有另外一個問題你沒有解決：你是互聯網還是內聯網？據報道，流媒體在各個代理服務器上都存在一些問題，就像您期望的那樣。因此，對於通用解決方案而言，長時間輪詢可能會更好地滿足您的需求 - 對於瞭解網絡基礎架構的Intranet，流式傳輸很可能是您更簡單，更好的性能解決方案。

Answer 3

流會更快，因爲數據只穿過導線的一種方式。通過輪詢，延遲至少是兩次。

輪詢是更有彈性的網絡中斷，因爲它不依賴於連接被保持開放。

我只是爲了健壯而去投票。

Answer 4

對於實時股票價格我絕對保持連接打開，並確保斷開用戶警報/重新連接。

Answer 5

StreamHub GWT Comet Adapter正是爲流式股票報價這種情況而設計的。例如：GWT Streaming Stock Quotes。它同時更新多個股票的股價。我認爲下面的實現是Comet，它基本上是通過HTTP流式傳輸的。

編輯：它爲每個瀏覽器使用不同的技術。引述網站：

有用於實現彗星 包括隱藏的iframe， 的XMLHttpRequest/SCRIPT長輪詢， 和嵌入式插件，如Flash幾種不同的底層 技術。 引入HTML 5周的WebSockets 到未來的瀏覽器將提供HTTP 流的 替代機制。 StreamHub使用「最適合」 方法利用每個 瀏覽器最高效的 和可靠的技術。

Answer 6

這其實並不重要。 HTTP1.1的連接重新協商開銷很小，你不會注意到任何重大的性能差異。

長輪詢的好處是兼容性和可靠性 - 使用代理，端口沒有問題，檢測斷開等

「真正的」流媒體的優勢將可能減少開銷，但作爲已經，這個提到好處很多，遠遠低於它的實際效果。

就個人而言，我發現一個精心設計的彗星服務器是對於大量的更新和/或服務器推送的最佳解決方案。