記一次Socket.IO長鏈服務的性能壓測

網易雲信IM系統中的Web版使用了Socket.IO實現瀏覽器環境下的長鏈服務；區別於常規的長鏈服務，爲該服務的壓測提出了一些新的挑戰，本文總結了測試過程當中的一些收穫供參考。
Part1測試工具選項
1、工具選型
Gatling
Node.js
JMeter
Java WebSocket
這些工具都是能夠支持WebSocket協議的工具，主要從如下幾個方面進行對比：
上手難易程度
測試資源開銷
和性能測試平臺結合的難易程度
2、對比過程
對比場景
（1）5000個用戶，每秒鐘發送100個登陸請求，並保持鏈接
（2）5000個用戶，每隔5s發送一條點對點消息，即發送消息頻率1000
工具使用過程

1. Gatling

工具簡介：Gatling是一款基於Scala 開發的高性能服務器性能測試工具，它主要用於對服務器進行負載測試，並分析和測量服務器的各類性能指標。
工具語言：Scala語言
工具官網：http://gatling.io/docs/2.0.0-...
相關代碼：

遇到的問題：
（1）scale語言比較陌生，腳本編寫時困難較多，目前暫未實現隔必定時間，即發心跳又發消息的場景；
（2）沒法和性能測試平臺結合，系統整合成本比較高；

1. Node.js + Socket.IO

工具簡介：
Node.js是一個基於Chrome V8引擎的JavaScript運行環境。Node.js使用了一個事件驅動、非阻塞式I/O的模型，使其輕量又高效；而Socket.IO是一個基於Node.js架構體系的且原生支持WebSocket協議，可用做實時通訊的軟件包。Socket.IO爲跨瀏覽器構建實時應用提供了完整的封裝，且徹底由JavaScript實現，語言更容易理解。
工具語言：JavaScript
工具官網：
• http://socket.io/docs/
• http://nodejs.cn/
相關代碼：

遇到問題：
（1）多節點併發分佈式控制
（2） 整合到現有的性能測試平臺

1. JMeter

工具簡介：
JMeter是比較常見的性能測試開源工具，支持多種協議而且能夠自定義java請求，更加靈活。
工具語言：
（1）Java
（2） JMeter xml腳本文件
工具官網：
http://jmeter.apache.org/user...
https://blog.flood.io/socket-...
相關代碼：

遇到問題
JMeter的工具本上是同步的，若是創建1萬個鏈接的話，須要啓動1萬個線程處理，所以不適合測試高併發長鏈接的場景。

1. Jetty WebSocket Client

工具簡介
Jetty提供了功能更強的WebSocket API，使用一個公共的核心API供WebSocket的服務端和客戶端使用。
工具語言: Java
工具官網
http://www.eclipse.org/jetty/
相關代碼

遇到問題
須要本身寫併發控制
3、對比結果總結
由於用來作性能壓測，因此考慮到壓測客戶端須要實現高併發請求，選擇Gatling和Socket.IO作了簡單的對比測試。

Part2 長鏈服務端性能問題的定位
如第一部分所述，咱們最終選擇用Socket.IO實現了併發壓測的長鏈客戶端，下面簡單說明下長鏈服務器端測試的一些收穫；
首先，簡單描述下被測試服務器的功能

1. 和前端Socket.IO客戶端保持長鏈接；
2. 解析前端JSON結構的數據包，並做二次封裝後抓發給後端APP服務，而且將後端APP服務轉發過來的響應包轉換成爲socketio能夠識別的json數據包，併發送給客戶端

爲此，咱們肯定該服務主要的測試點爲

1. 測試服務器能夠支撐的最大連接數：該測試點涉及到了TCP連接，以及咱們須要注意哪些參數，才能夠保證用戶創建的鏈接數目不會由於限制而達不到目標。
2. 每秒鐘能夠解析的包的數量：該測試點涉及到了網絡流量，若是已經達到了網絡流量的峯值時，會出現什麼樣的問題。

如下是此次測試過程當中遇到的一系列問題：
問題1：最大鏈接數只能達到65K+
65535，對於程序員來講，這是一個很敏感的數字，由於一臺服務器，限制的最大端口號即爲65535，因此出現這個問題後：
第一反應：端口號不夠用了。 分析認爲Link服務做爲服務端，對外提供的服務端口僅有一個，因此不存在服務端端口號不夠用的狀況；
第二反應：句柄數不夠用了。文件句柄數至關於文件的標識符，創建一條socket鏈接，一樣會使用一個文件句柄，而系統默認的單個進程使用的文件句柄爲1024；
對於這種須要保持大量鏈接的服務來講，通常狀況下都是須要修改文件句柄數的，文件句柄數修改的方法以下：
A）查看單個進程使用的最大文件句柄數的方法：

B）查看當前進程打開了多少個文件句柄呢：

C）修改Linux的最大文件句柄數限制的方法：
1）ulimit -n 65535
在當前session有效，用戶退出或者系統從新後恢復默認值
2）修改用戶下的.profile文件：在.profile文件中添加：ulimit -n 65535
只對當前用戶有效
3）修改文件/etc/security/limits.conf，在文件中添加：
（當即生效-當前session中運行ulimit -a命令沒法顯示）

4）修改文件/etc/sysctl.conf添加：

運行命令：/sbin/sysctl -p 使配置生效
可是修改文件句柄的限制後，該問題依然沒有獲得解決。
這個時候想到可使用dmesg查看系統日誌，dmesg命令能夠顯示Linux內核的環形緩衝區信息，能夠從中得到諸如系統架構、CPU和掛載的硬件，RAM等運行級別的大量系統信息,所以dmesg命令在設備故障的診斷方面是很是重要的。經過dmesg，查看到了以下問題：

從上面的信息可見conntrack表滿了，那麼conntrack表是作什麼的？
nf_conntrack/ip_conntrack用來跟蹤鏈接條目，會使用一個哈希表來記錄 established 的記錄
nf_conntrack 在 2.6.15 被引入，而 ip_conntrack 在 2.6.22 被移除，若是該哈希表滿了dmesg命令就會出現：
nf_conntrack: table full, dropping packet
如何修改conntrack表的大小

到此爲止，這個問題咱們算是解決了，總結下，遇到的網絡相關的知識點包括 文件句柄 和conntrack表。
問題2：在某些用例場景下，穩定鏈接只能創建3800+
這個問題的前提是某些時候，也就是說偶現的，這種狀況基本上能夠排除是應用程序內部的問題。那對於這個問題咱們使用了哪些定位手段呢？

1. watch和netstat 兩個命令

watch -d 按期查看一些信息，默認是2s；
netstat -st | grep ignored 查看TCP鏈接的一些統計信息；
可見有SYNs to LISTEN sockets ignored在不停增長，這代表收到鏈接創建過程當中的三次握手的ACK包，可是因各類緣由（包括accept隊列滿） 建立socket失敗；

1. ss -ln ： 查看進程對應的backlog的使用狀況

backlog：簡單理解來講，鏈接已經在TCP層創建成功（完成了三次握手的過程）可是尚未被應用程序所接受，這種狀況下，該連接會存放到backlog這樣一個緩衝隊列內
經過上面這個命令能夠看到應用程序的backlog隊列已經滿了，可是即使把這個值調整爲1024，該隊列仍是會滿的。
到這兒，咱們的定位過程陷入了僵局，下一步該怎麼定位呢？這期間咱們查看了內存信息，CPU使用狀況等，均沒有找對地方；可是在定位過程當中，咱們發現，有時候JStack、JProfiler等工具都沒法連上該服務了。
忽然想到文件句柄是否是滿了？又執行了如下幾條命令：

/proc/{pid}這個目錄下了對應了全部在運行的進程的相關信息，
經過查看/proc/{pid}/fd目錄下的個數咱們能夠看到當前進程使用的文件句柄數有多少。
經過查看limits文件裏面的值，能夠看到系統對該進程的一些限制，不幸的是，出現這個問題的時候，max open files這個值被限制爲了4096。
調整該值以後最終解決了這個問題
問題3：大量的鏈接創建不成功
當咱們解決了一個又一個的問題後，忽然發現高壓力下存在大量的鏈接創建不成功的問題，主要表如今：
原來：每秒鐘500個鏈接創建的請求時，5w個用戶均可以創建成功；
如今：每秒鐘500個鏈接創建的請求時，5w個用戶只有4w左右的鏈接能夠創建成功；
這個問題也花費了不短 的時間，咱們使用了各類命令查看各類網絡指標
經過netstat查看到send-q中有大量的消息堆積；
經過sar查看到有大量的重傳；
總結起來仍是TcpDump抓包比較效果更好，從測試的開始，咱們就只抓這一條鏈路上的包，且發送方和接收方，雙方都抓包：

而後經過Wireshark分析，能夠看到
發送方/客戶端：存在必定時間段發送出大量的重傳包
接收方/服務端：客戶端發送大量重傳包的這個過程當中，什麼都沒有收到
這基本說明網絡有問題
而後咱們經過netperf測試了下網絡帶寬的狀況，發現這兩臺機器之間的網絡上限只有21Mb，並且測試過程當中的網絡請求量是超過這個值的。因爲是在雲主機環境上，經過諮詢雲網絡相關的同事發現，問題緣由是由於雲主機之間的網絡QoS開啓限制致使的，限制了每臺雲主機之間的網絡帶寬最高位21Mb，超過這個值則會被丟包。

TCP的連接狀態圖
最後總結下在定位相似的網絡問題中一些常規的命令、工具和關注的方向
可使用如下命令

推薦使用如下工具

重點關注如下指標

想要獲取更多產品乾貨、技術乾貨，歡迎關注網易雲信博客。