使用四種框架分別實現1百萬websocket常連接的服務器
著名的 C10K 問題提出的時候, 正是 2001 年。這篇文章可以說是高性能服務器開發的一個標志性文檔，它討論的就是單機為1萬個連接提供服務這個問題，當時因為硬件和軟件的限制，單機1萬還是
一個非常值得挑戰的目標。但是時光荏苒，隨著硬件和軟件的飛速發展，單機1萬的目標已經變成了最簡單不過的事情。現在用任何一種主流語言都能提供單機
1萬的并發處理的能力。所以現在目標早已提高了100倍，變成C1000k，也就是一臺服務器為100萬連接提供服務。在2010年,2011年已經看到一些實現C1000K的文章了，所以在2015年，實現C1000K應該不是一件困難的事情。
本文是我在實踐過程中的記錄，我的目標是使用spran-websocket，netty, undertow和node.js四種框架分別實現C1000K的服務器，看看這幾個框架實現的難以程度，性能如何。開發語言為Scala和Javascript。
當然，談起性能，我們還必須談到每秒每個連接有多少個請求，也就是RPS數，還要考慮每條消息的大小。
一般來說，我們會選取一個百分比，比如每秒20%的連接會收發消息。我的需求是服務器只是push,客戶端不會主動發送消息。 一般每一分鐘會為這一百萬群發一條消息。
所以實現的測試工具每個client建立60000個websocket連接，一共二十個client。實際不可能使用20臺機器，我使用了兩臺AWS C3.2xlarge(8核16G)服務器作為客戶端機。每臺機器10個客戶端。
服務器每1分鐘群發一條消息。消息內容很簡單，只是服務器的當天時間。
最近看到360用Go實現的消息推送系統，下面是他們的數據：
目前360消息推送系統服務于50+內部產品，萬款開發平臺App，實時長連接數億量級，日獨數十億量級，1分鐘內可以實現億量級廣播，日下發峰值百億量級，400臺物理機，3000多個實例分布在9個獨立集群中，每個集群跨國內外近10個IDC。
</blockquote>四個服務器的代碼和Client測試工具代碼可以在github上下載。 (其實不止四種框架了，現在包括Netty, Undertow, Jetty, Spray-websocket, Vert.x 和 Node.js 六種框架的實現)
測試下來可以看到每種服務器都能輕松達到同時120萬的websocket活動連接，只是資源占用和事務處理時間有差別。120萬只是保守數據，在這么多連接情況下服務器依然很輕松，下一步我會進行C2000K的測試。
在測試之前我們需要對服務器/客戶機的一些參數進行調優。
服務器的參數調優
一般會修改兩個文件，/etc/sysctl.conf和/etc/security/limits.conf， 用來配置TCP/IP參數和最大文件描述符。
TCP/IP參數配置
修改文件/etc/sysctl.conf,配置網絡參數。
</tr> </tbody> </table> 數值根據需求進行調整。更多的參數可以看以前整理的一篇文章: Linux TCP/IP 協議棧調優 。
執行/sbin/sysctl -p即時生效。最大文件描述符
Linux內核本身有文件描述符最大值的限制，你可以根據需要更改：
- 系統最大打開文件描述符數：/proc/sys/fs/file-max
- 臨時性設置：echo 1000000 > /proc/sys/fs/file-max
- 永久設置：修改/etc/sysctl.conf文件，增加fs.file-max = 1000000
</ol> </li>- 進程最大打開文件描述符數
</ul>
使用ulimit -n查看當前設置。使用ulimit -n 1000000進行臨時性設置。
要想永久生效，你可以修改/etc/security/limits.conf文件，增加下面的行：
* hard nofile 1000000 </div> <div> * soft nofile 1000000 </div> <div> root hard nofile 1000000 </div> <div> root soft nofile 1000000 </div></pre></td> </tr> </tbody> </table>
還有一點要注意的就是hard limit不能大于/proc/sys/fs/nr_open，因此有時你也需要修改nr_open的值。
執行echo 2000000 > /proc/sys/fs/nr_open查看當前系統使用的打開文件描述符數，可以使用下面的命令：
</tr> </tbody> </table> 其中第一個數表示當前系統已分配使用的打開文件描述符數，第二個數為分配后已釋放的（目前已不再使用），第三個數等于file-max。
總結一下：
- 所有進程打開的文件描述符數不能超過/proc/sys/fs/file-max
- 單個進程打開的文件描述符數不能超過user limit中nofile的soft limit
- nofile的soft limit不能超過其hard limit
- nofile的hard limit不能超過/proc/sys/fs/nr_open
</ul>應用運行時調優
- Java 應用內存調優
</ol>
服務器使用12G內存，吞吐率優先的垃圾回收器：
</tr> </tbody> </table>
- V8引擎
</ol>
</tr> </tbody> </table> OutOfMemory Killer
如果服務器本身內存不大，比如8G，在不到100萬連接的情況下，你的服務器進程有可能出現"Killed"的問題。 運行dmesg可以看到
</tr> </tbody> </table> 這是Linux的OOM Killer主動殺死的。 開啟oom-killer的話，在/proc/pid下對每個進程都會多出3個與oom打分調節相關的文件。臨時對某個進程可以忽略oom-killer可以使用下面的方式:
echo -17 > /proc/$(pidof java)/oom_adj
解決辦法有多種，可以參看文章最后的參考文章,最好是換一個內存更大的機器。客戶端的參數調優
在一臺系統上，連接到一個遠程服務時的本地端口是有限的。根據TCP/IP協議，由于端口是16位整數，也就只能是0到 65535，而0到1023是預留端口，所以能分配的端口只是1024到65534，也就是64511個。也就是說，一臺機器一個IP只能創建六萬多個長連接。
要想達到更多的客戶端連接，可以用更多的機器或者網卡，也可以使用虛擬IP來實現,比如下面的命令增加了19個IP地址，其中一個給服務器用，其它18個給client,這樣
可以產生18 * 60000 = 1080000個連接。
</tr> </tbody> </table> 修改/etc/sysctl.conf文件：
</tr> </tbody> </table> 執行/sbin/sysctl -p即時生效。
服務器測試
實際測試中我使用一臺AWS C3.4xlarge (16 cores, 32G memory)作為應用服務器，兩臺AWS C3.2xlarge (8 cores, 16G memory)服務器作為客戶端。
這兩臺機器作為測試客戶端綽綽有余，每臺客戶端機器創建了十個內網虛擬IP, 每個IP創建60000個websocket連接。客戶端配置如下：
/etc/sysctl.conf配置
</tr> </tbody> </table> /etc/security/limits.conf配置
* soft nofile 2000000 </div> <div> * hard nofile 2000000 </div> <div> </div> <div> * soft nproc 2000000 </div> <div> * hard nproc 2000000 </div></pre></td> </tr> </tbody> </table>
服務端配置如下：
/etc/sysctl.conf配置
</tr> </tbody> </table> /etc/security/limits.conf配置
* soft nofile 2000000 </div> <div> * hard nofile 2000000 </div> <div> </div> <div> * soft nproc 2000000 </div> <div> * hard nproc 2000000 </div></pre></td> </tr> </tbody> </table>
Netty服務器
- 建立120萬個連接，不發送消息，輕輕松松達到。內存還剩14G未用。
</ul>
[roocolobu ~]# ss -s; free -mTotal: 1200231 (kernel 1200245)TCP: 1200006 (estab 1200002, closed 0, orphaned 0, synrecv 0, timewait 0/0), ports 4</div> <div> Transport Total IP IPv6 </div> <div> * 1200245 - - </div> <div> RAW 0 0 0 </div> <div> UDP 1 1 0 </div> <div> TCP 1200006 1200006 0 </div> <div> INET 1200007 1200007 0 </div> <div> FRAG 0 0 0 </div> <div> </div> <div> total used free shared buffers cached </div> <div> Mem: 30074 15432 14641 0 9 254 </div> <div> -/+ buffers/cache: 15167 14906 </div> <div> Swap: 815 0 815 </div></pre></td> </tr> </tbody> </table>
- 每分鐘給所有的120萬個websocket發送一條消息，消息內容為當前的服務器的時間。這里發送顯示是單線程發送，服務器發送完120萬個總用時15秒左右。
</ul>
</tr> </tbody> </table> 發送時CPU使用率并不高，網絡帶寬占用基本在10M左右。
</tr> </tbody> </table> 客戶端(一共20個，這里選取其中一個查看它的指標)。每個客戶端保持6萬個連接。每個消息從服務器發送到客戶端接收到總用時平均633毫秒，而且標準差很小，每個連接用時差不多。
Active WebSockets for eb810c24-8565-43ea-bc27-9a0b2c910ca4count = 60000WebSocket Errors for eb810c24-8565-43ea-bc27-9a0b2c910ca4count = 0</div> <div> -- Histograms ------------------------------------------------------------------ </div> <div> Message latency for eb810c24-8565-43ea-bc27-9a0b2c910ca4 </div> <div> count = 693831 </div> <div> min = 627 </div> <div> max = 735 </div> <div> mean = 633.06 </div> <div> stddev = 9.61 </div> <div> median = 631.00 </div> <div> 75% <= 633.00 </div> <div> 95% <= 640.00 </div> <div> 98% <= 651.00 </div> <div> 99% <= 670.00 </div> <div> 99.9% <= 735.00 </div> <div> </div> <div> -- Meters ---------------------------------------------------------------------- </div> <div> Message Rate for eb810c24-8565-43ea-bc27-9a0b2c910ca4 </div> <div> count = 693832 </div> <div> mean rate = 32991.37 events/minute </div> <div> 1-minute rate = 60309.26 events/minute </div> <div> 5-minute rate = 53523.45 events/minute </div> <div> 15-minute rate = 31926.26 events/minute </div></pre></td> </tr> </tbody> </table>
Spray服務器
- 建立120萬個連接，不發送消息，輕輕松松達到。它的內存相對較高，內存還剩7G。
</ul>
[root@colobu ~]# ss -s; free -mTotal: 1200234 (kernel 1200251)TCP: 1200006 (estab 1200002, closed 0, orphaned 0, synrecv 0, timewait 0/0), ports 4</div> <div> Transport Total IP IPv6 </div> <div> * 1200251 - - </div> <div> RAW 0 0 0 </div> <div> UDP 1 1 0 </div> <div> TCP 1200006 1200006 0 </div> <div> INET 1200007 1200007 0 </div> <div> FRAG 0 0 0 </div> <div> </div> <div> total used free shared buffers cached </div> <div> Mem: 30074 22371 7703 0 10 259 </div> <div> -/+ buffers/cache: 22100 7973 </div> <div> Swap: 815 0 815 </div></pre></td> </tr> </tbody> </table>
- 每分鐘給所有的120萬個websocket發送一條消息，消息內容為當前的服務器的時間。
</ul>
CPU使用較高，發送很快，帶寬可以達到46M。群發完一次大約需要8秒左右。
</tr> </tbody> </table>
</tr> </tbody> </table> 客戶端(一共20個，這里選取其中一個查看它的指標)。每個客戶端保持6萬個連接。每個消息從服務器發送到客戶端接收到總用時平均1412毫秒，而且標準差較大，每個連接用時差別較大。
Active WebSockets for 6674c9d8-24c6-4e77-9fc0-58afabe7436fcount = 60000WebSocket Errors for 6674c9d8-24c6-4e77-9fc0-58afabe7436fcount = 0</div> <div> -- Histograms ------------------------------------------------------------------ </div> <div> Message latency for 6674c9d8-24c6-4e77-9fc0-58afabe7436f </div> <div> count = 454157 </div> <div> min = 716 </div> <div> max = 9297 </div> <div> mean = 1412.77 </div> <div> stddev = 1102.64 </div> <div> median = 991.00 </div> <div> 75% <= 1449.00 </div> <div> 95% <= 4136.00 </div> <div> 98% <= 4951.00 </div> <div> 99% <= 5308.00 </div> <div> 99.9% <= 8854.00 </div> <div> </div> <div> -- Meters ---------------------------------------------------------------------- </div> <div> Message Rate for 6674c9d8-24c6-4e77-9fc0-58afabe7436f </div> <div> count = 454244 </div> <div> mean rate = 18821.51 events/minute </div> <div> 1-minute rate = 67705.18 events/minute </div> <div> 5-minute rate = 49917.79 events/minute </div> <div> 15-minute rate = 24355.57 events/minute </div></pre></td> </tr> </tbody> </table>
Undertow
- 建立120萬個連接，不發送消息，輕輕松松達到。內存占用較少，還剩余11G內存。
</ul>
[root@colobu ~]# ss -s; free -mTotal: 1200234 (kernel 1200240)TCP: 1200006 (estab 1200002, closed 0, orphaned 0, synrecv 0, timewait 0/0), ports 4</div> <div> Transport Total IP IPv6 </div> <div> * 1200240 - - </div> <div> RAW 0 0 0 </div> <div> UDP 1 1 0 </div> <div> TCP 1200006 1200006 0 </div> <div> INET 1200007 1200007 0 </div> <div> FRAG 0 0 0 </div> <div> </div> <div> total used free shared buffers cached </div> <div> Mem: 30074 18497 11576 0 10 286 </div> <div> -/+ buffers/cache: 18200 11873 </div> <div> Swap: 815 0 815 </div></pre></td> </tr> </tbody> </table>
- 每分鐘給所有的120萬個websocket發送一條消息，消息內容為當前的服務器的時間。
</ul>
群發玩一次大約需要15秒。
</tr> </tbody> </table> 客戶端(一共20個，這里選取其中一個查看它的指標)。每個客戶端保持6萬個連接。每個消息從服務器發送到客戶端接收到總用時平均672毫秒，而且標準差較小，每個連接用時差別不大。
Active WebSockets for b2e95e8d-b17a-4cfa-94d5-e70832034d4dcount = 60000WebSocket Errors for b2e95e8d-b17a-4cfa-94d5-e70832034d4dcount = 0</div> <div> -- Histograms ------------------------------------------------------------------ </div> <div> Message latency for b2e95e8d-b17a-4cfa-94d5-e70832034d4d </div> <div> count = 460800 </div> <div> min = 667 </div> <div> max = 781 </div> <div> mean = 672.12 </div> <div> stddev = 5.90 </div> <div> median = 671.00 </div> <div> 75% <= 672.00 </div> <div> 95% <= 678.00 </div> <div> 98% <= 684.00 </div> <div> 99% <= 690.00 </div> <div> 99.9% <= 776.00 </div> <div> </div> <div> -- Meters ---------------------------------------------------------------------- </div> <div> Message Rate for b2e95e8d-b17a-4cfa-94d5-e70832034d4d </div> <div> count = 460813 </div> <div> mean rate = 27065.85 events/minute </div> <div> 1-minute rate = 69271.67 events/minute </div> <div> 5-minute rate = 48641.78 events/minute </div> <div> 15-minute rate = 24128.67 events/minute </div> <div> Setup Rate for b2e95e8d-b17a-4cfa-94d5-e70832034d4d </div></pre></td> </tr> </tbody> </table>
node.js
node.js不是我要考慮的框架，列在這里只是作為參考。性能也不錯。
Active WebSockets for 537c7f0d-e58b-4996-b29e-098fe2682dcfcount = 60000WebSocket Errors for 537c7f0d-e58b-4996-b29e-098fe2682dcfcount = 0</div> <div> -- Histograms ------------------------------------------------------------------ </div> <div> Message latency for 537c7f0d-e58b-4996-b29e-098fe2682dcf </div> <div> count = 180000 </div> <div> min = 808 </div> <div> max = 847 </div> <div> mean = 812.10 </div> <div> stddev = 1.95 </div> <div> median = 812.00 </div> <div> 75% <= 812.00 </div> <div> 95% <= 813.00 </div> <div> 98% <= 814.00 </div> <div> 99% <= 815.00 </div> <div> 99.9% <= 847.00 </div> <div> </div> <div> -- Meters ---------------------------------------------------------------------- </div> <div> Message Rate for 537c7f0d-e58b-4996-b29e-098fe2682dcf </div> <div> count = 180000 </div> <div> mean rate = 7191.98 events/minute </div> <div> 1-minute rate = 10372.33 events/minute </div> <div> 5-minute rate = 16425.78 events/minute </div> <div> 15-minute rate = 9080.53 events/minute </div></pre></td> </tr> </tbody> </table>
參考文檔
- HTTP長連接200萬嘗試及調優
- 100萬并發連接服務器筆記之1M并發連接目標達成
- 知乎：如何實現單服務器300萬個長連接的？
- 構建C1000K的服務器
- 千萬級并發實現的秘密
- C1000k 新思路：用戶態 TCP/IP 協議棧
- https://github.com/xiaojiaqi/C1000kPracticeGuide
- 600k concurrent websocket connections on AWS using Node.js
- https://plumbr.eu/blog/memory-leaks/out-of-memory-kill-process-or-sacrifice-child?utm_source=feedly&utm_reader=feedly&utm_medium=rss&utm_campaign=rss
- http://it.deepinmind.com/java/2014/06/12/out-of-memory-kill-process-or-sacrifice-child.html
- https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/s-memory-captun.html
- http://www.nateware.com/linux-network-tuning-for-2013.html#.VV0s6kawqgQ
- http://warmjade.blogspot.jp/2014_03_22_archive.html
- http://mp.weixin.qq.com/s?__biz=MjM5NzAwNDI4Mg==&mid=209282398&idx=1&sn=9ffef32b3ab93d1e239c9dc753a3a9bb
</ol> 來自：本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！相關經驗
相關資訊
sesese色