※ 引述《howardwang (Howard)》之銘言： : 想請教一個觀念問題： : 　　為了實作server push， : 所以想知道， : 　　有沒有方法來解決comet或long polling時佔用web server連線數的問題。 : 因為機器的capacity不大，系統也小，所以允許的同時連線數不多， 我只知道隨便一台機器要來個上k的連線都不難 只是server端架設正不正確 如果你要用PHP+Apache這種方法直接玩long polling 資源消耗絕對除了浪費還是浪費 這只是方便而已 : 　　如果用comet的話，一個使用者就會一直佔據client和server之間的一條連線， : 　　這樣子可能使用者會進不來網頁， : 後來聽說了web socket，本來以為可以解決連線數的問題， : 　　但看了一些網站之後，覺得web socket應該還是會佔掉一條連線。 : 既然如此，為什麼不要用AJAX+long polling就好了？ 很簡單long polling始終不是"雙向" 連線數向來都不是問題真正重點 那些搞串流 搞即時通訊 更遑論是大型P2P 隨便一個同時連線數對一般網頁系統來說可能都是天文數字了 websocket主要特點在於它是個對HTTP擴充而成的"雙向"連線 而不是原先HTTP那種客戶端發請求 server只能被動回應的形式 long polling說實話只是種hack而已 當server端的push量一大的話 long polling會造成大量的request (先不說比起websocket還可能有短暫斷開的這個問題要額外處理) 這中間那大量header對server資源除了浪費外 還是浪費跟浪費 當然這邊來看你指的連線數應該是PHP-FPM之類那種同時處理資料的連線... 不過會有這顧慮表示你從根本就選了不正確的方法 : 　　還是說，我的認知有錯？web socket不會佔住連線？ : 　　又或者，有不會一直佔據連線的server push方法嗎？ 簡單來說吧 你想要做一個server push的動作的話 後端架構請改用"常駐"模式的跑法 像是Java Servlet,Python,NodeJS,RoR這類 除非你打算讓PHP也搞常駐 不過絕大多數的PHP都是被動式的服務 而所謂連線數的瓶頸在於這PHP解譯器同時能執行的數量 當你後端改成"常駐"的模式後 正常寫法會將server push這部分額外拆開處理 這時不管是處理long polling還是websocket的部分 除了最初判斷request類型外 確定是server push的部分後就會把那連線丟到另一個pool裡去讓他wait 不去搶request解譯那部份的資源(已經離開request解譯部分) 而那pool裡的東西只有要push的時候才另外拉出來把訊息給丟出去 不過這邊很先入為主的認定原本是用PHP啦... 如果不是PHP狀況也是一樣 只是你處理上的觀念要改變才行 並不是像以往寫網頁一樣 等待只是放在那不輸出 雖然long polling這樣寫也是能用 不過可以保證 沒大網站是這樣做的 因為那樣server再多都不夠用 : 　　謝謝。 打得其實有點亂XDD 對了 如果你是寫網頁放在一般的網頁空間(一般的LAMP空間) 那根本上是無解的 因為架構打從一開始就不適合server push --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.115.216.102 ※ 編輯: danny8376 來自: 140.115.216.102 (11/26 03:33)