如何看待Phoenix用40核128G內存的機器只能同時保持僅僅200萬WebSocket連接？

01-15

參考: http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections
而 Go語言在24核64G內存的機器上就能輕鬆同時保持超過100萬長連接(大約160萬)

周洋 - GopherChina

2008年跟一幫兄弟玩erlang，搞web im，搞廣告統計，都是照著千萬級長連接做的。

果然是最近這些年移動開發和前端開發火起來以後，後端工程師都斷檔了。以至於就這臭水平也好意思拿出來。

先不談語言，維持長連接這事的關鍵在於如何繞開或者優化OS層面的socket管理。建立個高效的索引找到所需的socket。然後長連接較多時，就會佔用大量內存。就這樣。

OS級別先不談，畢竟最近幾年有啥內核級更新沒有跟進。以繞開的OS的玩法說，就是直接走raw_socket。幾年前OS內核默認為每個連接的接收和發送各分配8KB的緩衝區。所以那時想要在64GB機器上做千萬級長連接，這緩衝區大小不改掉是肯定不行的。而且就算改掉，此類長連接服務本身大部分時間只是維持連接，通信極少。所以這個緩衝區還是很浪費的。而基於raw_socket則簡單的多。接到IP包做一下分片組裝，組TCP包，校驗一下checksum，ack，seq序號。對應用層長度為0的包做一下連接和斷開的處理。定期幹掉沒有響應的連接。組裝好的TCP里應用層的包就交給上層應用。

raw_socket的玩法就是要自己寫長連接socket管理所需的索引庫。每個到來的包要知道喚醒哪個session去處理。要發送數據時也要知道該由哪個IP和埠發出去。

2 million is a figure we are pleased with. However, we did not quite max out the machine and we have not yet made any effort toward reducing the memory usage of each socket handler. In addition, there are more benchmarks we will be performing. This particular set of benchmarks was set exclusively around the number of simultaneous open sockets.

到你這變成只能了？

題主肯定知道 elixir 這個業務層面的東西完全依賴 erlang VM，要繼續 erlang VS golang 的話找 erlang 吵去，請把 phoenix 換成 cowboy，別把 elixir 牽扯進來，謝謝。

要是OJ網站也可以200萬並發秒回結果，那該多好啊。

BEAM 的問題。

BEAM 其實沒有宣傳的那麼好，正常的情況下 15核以上 VM 就會虛掉。

anti-Erlang 的論點裡面有一條就是：BEAM 在多核心伺服器的表現還不如定製 JVM 好 ♂?。

啥都不幹，就連著？這種測試不是耍流氓嗎？

為啥我測了下掛連接14g可以掛100w？做這種接入層不做優化么？

請教一下GO語言是怎麼做到的?一般每一條TCP長連接都需要單獨佔用一定數量的內存緩衝區,64G內存,假設全用來當TCP緩衝,對於100萬條連接,只能給每條連接提供64K的緩衝區,這個數值不會太小了嗎?

高並發也要按照基本法。

要按照項目業務需求來啊，當然架構的決定權也是很重要的，任何語言都是適配於項目和架構設計的。