作者：聶永，新浪微博技術專家。負責移動端訊息應用架構底層基礎設施維護和優化等，目前致力於推廣效能驅動模式推動系統健康發展的理念。
本文為《程式設計師》原創文章，未經允許不得轉載，更多精彩文章請訂閱《程式設計師》

微博產品後端服務團隊在資源受限情況下基於Tsung提供了一套開箱即用的100萬用戶效能壓測工具套件，推動兩名能力和經驗都欠缺的中初級工程師，不但順利完成支援海量使用者的線上聊天室專案任務，同時保證了該業務系統整體處理效能可控並按照預期方式向前推進。

需求 & 背景

前段時間我們為微博App增加一個視訊直播聊天室功能，這是一個需要支援海量級手機終端使用者一起參與、實時互動的強互動系統，建立在私有協議之上、有狀態的長連線TCP應用。和其他專案一樣，在立項之初，就已確定所構建系統至少能夠承載100萬用戶容量，以及業務處理效能最低標準。

當時研發力量投入有限，一名中級工程師 + 一名初級工程師，兩人研發經驗和實踐能力的欠缺不足以完成系統容量和處理效能的考核目標，這是擺在眼前最為頭疼問題。聊天室業務邏輯清晰並已文件化，倒不用太擔心功能執行正確，除了自我驗證外，還會有QA部門幫忙校驗。這驅使我們在軟體工程角度去思考，如何通過行之有效的手段或工具去推動研發同學專案順利完成專案效能考核目標。

延伸一下，新專案構建之初，自然要關注總體處理效能目標的。但從軟體生命週期角度考慮，還應該考慮到系統後續維護和迭代。所謂工欲善其事，必先利其器，因此我們需要提供一個完善的開箱即用、支援海量使用者的效能壓測基礎工具套件，既要能夠保證系統處理效能是可測量的，又要能夠為每一次版本釋出時、常規迭代後再次驗證系統性能目標。帶著這一目標，下面將逐一展開我們如何構建百萬使用者效能壓測工具套件的過程以及注意事項。

效能壓測工具選擇

團隊所能夠支配的空閒伺服器數量幾乎為零，這是現狀。所負責業務線的大部分伺服器配置為16GB記憶體、24個CPU核心左右，每時每刻都在跑著具體的業務。若留心觀察，一般晚上九、十點之後資源利用率高，而白天時間CPU、記憶體、網路等資源大概會剩餘30%-60%左右，頗為浪費，如何將這部分資源充分利用起來，是一個需要思索的問題。

針對100萬用戶這樣超大容量壓測需求，要求每臺壓測機要能夠負載儘可能多的使用者量。試想，若一臺壓測機器承載1萬用戶，那麼就會需要使用到100臺，單純所需數量就是一件讓人很恐怖的事情。

若是單獨為效能壓測申請伺服器資源，一是流程審批流程較為繁冗，二是因為壓測行為不是每時每刻都會執行高頻事件，會造成計算資源極大浪費。本著節約資源理想方式就是充分利用現有的空閒計算資源用於執行效能壓力測試任務。

【眾多選擇】
當前市面上能夠提供效能壓測的工具很多，選擇面也能很廣泛，下面我將結合實際具體業務逐一分析和篩選。
TcpCopy
線上引流模式，針對新專案或全新功能就不太合適了，業務層面若需要一定量的業務邏輯支援，很難做得到。

JMeter
Java編寫，在執行1萬個壓測使用者執行緒時，CPU上下文切換頻繁，大量併發時會有記憶體溢位問題，很顯然也不是理想的選擇。

nGrinder
圖表豐富，架構很強大，堆疊依賴項太多，學習成本很高。
需要額外掌握Python等指令碼語言，雖針對程式設計師友好，不是所有人都可以馬上修改。
數十個執行緒至少佔用4GB記憶體，一臺機器上要模擬5萬個使用者，不但CPU上下文切換恐怖，16GB小記憶體機器更是遠遠滿足不了。
針對伺服器資源充足的團隊，可以考慮單獨機器部署或Docker部署組成叢集，針對我們團隊情況就不合適了，想免費做到是不可能的。

Tsung
完成同樣效能壓測功能，卻沒有第三方庫依賴，獨立一套應用程式。
雖然所測試服務是I/O密集型，但所佔用記憶體不會成為瓶頸。
可能會觸及到Erlang語言，但我們現在工作用的語言就是Erlang，也就不存在什麼問題了。

其他

綜合所述，Tsung預設情況下消耗低，可充分利用現有伺服器空閒計算資源，線上多次實踐也證實資源佔用始終在一個理想可控的範圍內，具有可讓百萬使用者壓測執行的費用成本降低為0的能力，這也是我們選擇Tsung的目的所在。

【為什麼是Tsung？】

Tsung是一個有著超過15年曆史積累的效能壓測工具，本身受益於Erlang天生支援併發和分散式以及實時性的特性，其程序的建立和執行非常廉價，一臺機器上輕輕鬆鬆建立上百萬個程序。其提供一個使用者對應一個程序的隔離處理機制，單機支援虛擬使用者的使用者數量可支援若十萬、百萬級別，只要機器資源充足（但總體來講受制於受制於網路、記憶體等資源，後面會具體解釋）。單機計算能力總是有限的，Tsung的目的就是要把多臺伺服器橫向擴充套件成分散式叢集，從而可以對外提供一致的海量效能壓力測試服務。

協議層，Tsung不但支援TCP/UDP/SSL傳輸層協議等，而且應用層協議，已支援諸如WebDAV/WebScoket/MQTT/MySQL/PGSQL/AQMP/Jabber/XMPP/LDAP等。預設情況下，開箱即用，憑藉著社群的支援，市面上能夠找到的公開通用協議，都有相應官方或第三方外掛支援。

和nGrinder相比，Tsung定位於提供一個強大的效能測試工具，在易用性和強大可擴充套件方面保持了一個平衡點。基於XML + DSL提供可配置、可程式設計的能力。比如我們可設定上一次的響應結果作為下一次請求內容，我們可配置多種業務協議、多個業務場景作為一個整體壓測等。盡力抽象所要壓測的情景吧，你不會失望的。
服務資源佔用方面，以單機模擬5萬長連線使用者為例，有資料正常互動情況下，記憶體佔用不到3GB，CPU佔用不到兩核，十分經濟。

【Tsung的叢集架構 & 流程】

知其然知其所以然，還是需要掌握Tsung叢集大致流程的。這是一種強主從模型，簡單流程梳理如下：

• 主節點（tsung_controller）通過SSH通道連線到從伺服器啟動從節點執行時環境；
• 主節點通過RPC方式批量啟動從節點例項（tsung client）；
• 主節點為每一個從節點啟動會話監控，控制會話速度，控制每一個壓測使用者程序ts_client生成速度；
• 從節點請求主節點具體業務程序，獲取會話指令以及會話具體內容；
• 從節點建立到目標壓測伺服器的SOCKET網路連線，開始會話；
• 主節點可以通過SSH通道連線到目標壓測伺服器，啟動從節點，收集資料（可選）。
• 再深入一些，以MQTT協議為例，每一種具體協議的支援可分為檔案解析和會話動作的執行，運作機制不復雜，當我們在需要時可以遵循介面約定實現私有協議支援，也不是難事。

100萬用戶壓測需要多少臺機器?

要執行100萬用戶的效能壓測，首先預估需要多少臺壓測伺服器才能夠滿足要求。在Tsung中，一個壓測使用者對應於一個程序，一個程序預設會開啟一條連線到伺服器的TCP網路連線。只要記憶體夠用（I/O密集型的應用一般吃記憶體），基於Erlang開發的應用程式，輕輕鬆鬆應對幾十萬、上百萬的程序不是問題。那麼我們需要把注意力轉移到Linux網路資源上。一臺伺服器所能夠提供網路IP地址數量和記憶體大小等主要因素，直接決定了能夠承載的對外建立的網路連線數，下面我們把主要的影響因素一一列出並分析。

【網路四元組和總連線數】
說到網路連線抽象層面構成元素，針對本機對外建立的一個TCP連線而言，需要使用到本機的IP地址（localip）和埠（localport），以及遠端的主機的IP地址（targetip）和埠（targetport），可以使用網路四元組進行呈現一個連線的最小構成：

{local_ip，local_port，target_ip，target_port}

我司目前所使用的伺服器作業系統大多為Centos 6.x版，受制於Linux核心限制，無論目標伺服器連線地址如何變化，單機對外建立的連線數量是有限的：總連線數=本機可用IP地址數量×本機可用埠的數量。

明白了總連線數的計算方式，那麼可以按圖索驥，從每一個計算因子上去考慮如何擴大其連線數。
注：若要除錯TCP網路四元組，諸位可使用bindp這個小工具：https://github.com/yongboy/bindp，十分方便。

【Linux核心埠數量的限制】
眾所周知，在Linxu系統中，埠的數值範圍為無符號short型別，值範圍為1 ~ 65535。一般來講1 ~ 1023範圍預設只有Root使用者有許可權使用，普通使用者可以使用區間範圍1025 ~ 65535，約6萬。

但你要考慮這中間很多的埠可能被已執行的程式佔用，不妨打個折降低預期範圍，留有5萬左右的可用數值，以作緩衝。
我們可通過sysctl命令確認當前可用的埠範圍，以作參考：

bash sysctl -a | grep net.ipv4.ip_local_port_range

若範圍空間太小，比如1024 ~ 35525，那就需要主動擴大一下：

bash sysctl -w net.ipv4.ip_local_port_range="1024 65535" 
sysctl -p

【擴充套件閱讀：IP可用數量的延伸】
有三種比較經濟方式可擴充套件IP地址可用數量。

第一種，針對Linux核心 >= 3.9的Linux伺服器而言，可設定SO_REUSEPORT核心引數進行支援；對外一個連線的四元組，將不再僅侷限於本機IP地址和埠兩個元素，整個網路四元組任何一個元素若有變化，都可以認為是一個全新的TCP連線，那麼針對單機而言可用總連線數上限可以這樣計算：

總連線數 = 本機可用IP地址數量×本機可用埠的數量×遠端伺服器可訪問IP地址數量×遠端伺服器可訪問埠數量。

注：

1. 遠端伺服器指的是要壓測的業務伺服器提供了多個訪問地址（IP地址:埠）訪問，但都指向同一個業務服務介面；
2. 一般而言，一個業務服務只會開放一個IP地址和埠。

第二種方式，使用IP地址別名的方式，為本機繫結額外的可用的IP地址：

bash ifconfig eth0:1 10.10.10.101 netmask 255.255.255.0

注：所繫結的IP地址一定是可用的，否則會導致壓測機和被壓測的伺服器之間無法成功建立連線。

第三種，可用考慮使用IP_TRANSPARENT（Linux kernel 2.6.28新增支援）特性支援。在你記憶體足夠大的情況下（比如擁有64GB ~ 128GB記憶體），假如壓測機A的IP地址為10.10.9.100，公司內網有一個IP段10.10.10.0暫時沒有被使用，你可以通過ip route工具設定一臺機器佔用完整一個IP地址段支援。

壓測機需要為物理網絡卡eth1新增路由規則，以便能夠正常處理來自新增IP段的往返資料包：

bash ip rule add iif eth1 tab 100 ip route add local 0.0.0.0/0 dev lo tab 100

同時需要在被壓測的伺服器上新增路由規則，方便在傳送響應資料包時候能夠找到被路由的介面地址：

bash route add -net 10.10.10.0 netmask 255.255.255.0 gw 10.10.9.100

這樣一折騰，壓測機A的可用IP地址就多出來250多個全新的IP地址了。
注：其實，還可以虛擬若干個Docker例項達到這個目的。 有興趣的同學，可以進一步參考：Tsung筆記之IP地址和埠限制突破篇，以便獲得更多資料支援。

【記憶體因素】
針對大部分應用而言，Tsung預設網路堆疊傳送和接收緩衝區都是16KB，完全夠用了。一個網路連線 = 一個使用者 = 一個程序，每程序業務佔用約10KB，粗略算下來，一個不太複雜使用者邏輯上記憶體佔用不到50KB記憶體。
按照這個方式計算，1萬用戶可佔用500M記憶體，單機要支援6W使用者，再加上程式自身佔用記憶體，整個Tsung例項大約會佔用4GB記憶體。實際上測試中，在每臺壓測機分配5萬用戶情況下記憶體使用情況，可以見圖2。

【注意檔案控制代碼】
一個網路連線佔用一個檔案控制代碼，可用檔案控制代碼數一定要大於對外建立的連線數。可使用ulimit檢視限制的數量：

bash ulimit -Sn ulimit -Hn

若此值太小，根據實際情況調整，設定大一些，比如下面設定的30萬連線控制代碼限制，大於當前伺服器日常對外提供的連線數峰值 + 壓測從機對外建立的連線數，有緩衝餘地，可輕鬆應對大部分任務：

bash echo "* soft nofile 300000" >> /etc/security/limits.conf echo "* hard nofile 300000" >> /etc/security/limits.conf

還需要關注一下當前伺服器總的檔案控制代碼最大開啟數量限制：

bash cat /proc/sys/fs/file-max

此值不能夠小於上面所設定的nofile的值，否則需要大一些：

bash sysctl -w fs.file-max=300000 sysctl -p

【百萬使用者壓測機組成】

說完影響因素，現在我們可計算一下，要壓測100萬用戶，理論上需要多少臺伺服器支援：

1. 每一個IP地址可以支援6萬個TCP連線同時開啟，那麼100萬個呢，100萬/6萬 ≈ 17個IP地址就夠了；
2. 1萬用戶大約佔用500MB記憶體，100萬用戶大概將佔用500MB×100萬 / 1000MB ≈ 50GB記憶體。

總之理論上，一臺64GB記憶體伺服器 + 17個可用IP地址，可以單獨完成100萬用戶的壓測任務。
注：我們忽略了CPU資源的需求，一般壓測是I/O密集型，所耗費CPU資源不是很多，但也要小心，有時需要降低或關閉掉在壓測端進行一些高頻的資料校驗行為。

理論和現實總是有差距存在，要做100萬用戶的壓測，如上所述，我們沒有大量空閒伺服器，有的是若干16GB小記憶體、單一內網IP地址的線上伺服器，需要因地制宜：

1. 留有緩衝餘地，每一臺壓測機平均分配5萬個使用者；
2. 1臺伺服器用作壓測主機；
3. 20臺線上伺服器作為壓測機。

提前計算和準備好壓測使用的伺服器，下面該進入設計業務壓測會話內容環節了。

設計業務壓測會話內容

緊密貼合業務設計壓測，會話內容將是需要考慮的重心。

【壓測連線資訊】
怎麼填寫壓測連線伺服器地址、壓測從機，根據Tsung手冊操作即可。篇幅所限，不再贅述。

若是壓測單臺業務伺服器，使用者每秒生成速率需要避免設定過大。因為業務型服務，一般以處理具體自身業務為先，在使用者每秒產生速率過快情況下，針對新建網路連線的處理速度就不會太快。

比如我們實踐中設定每秒產生500個使用者對線上若干臺伺服器壓測，可避免因為產生過快影響到線上其他具體業務。
實踐壓測環節中，可能需要考慮很多的事情：

1. 會不會突然之間對LVS網路通道產生影響，需要和網路組同事進行協調；
2. 會不會因為突然之間的壓力導致影響到其他現有服務；
3. 一般建議，非封閉的網路環境下將使用者每秒壓力產生速度設定小一點，保險一些。

【設計壓測會話內容】
壓力測試會話內容的編寫，有三個原則需要注意：模擬、全面和強度。

我們在設計壓測會話時，一定要清楚所開發系統最終面向的使用者是誰，其使用習慣和特徵分別是什麼，一定要儘可能的去復現其使用場景。其次，需要模擬的使用者會話內容要全面覆蓋使用者互動的各個方面，比如聊天室專案中，一個使用者從加入房間，中間流程包括點贊、打賞、光柱、發言等行為，中間間隔的心跳等，最後可選擇的退出行為，其業務場景，完整的體現在編寫的壓測場景中了。另外，針對業務場景特點，還針對每一個具體的行為，還要考慮其執行次數等，簡簡單單走一遍流程，也就失去了效能壓力測試的意義了。

下表是在壓測聊天室這個業務時壓測會話，包含了一個終端使用者的完整互動。

安裝和部署

Tsung安裝部署要求簡單：

1. 所有壓測伺服器上安裝有同樣版本的Erlang和Tsung
2. 伺服器之間SSH通道需要設定成免金鑰自動登入形式

這針對一般的機房環境是沒有什麼問題，但網路環境是很複雜的，問題總是會多過設想。

【SSH不可用時的替代方案】
但SSH通道會被系統管理員出於安全考慮禁用，導致Tsung主節點無法啟動從節點，無法建立壓測叢集。我司機房網路環境就是如此，既然SSH不可使用，那麼需要尋找/編寫一個替代者。

一般情況下，Tsung主節點啟動之後，從tsung.xml檔案中讀取從機列表，進而啟動：

erlang slave:start(node_slave, bar, "-setcookie mycookie")

然後被翻譯為類似於ssh HOSTNAME/IP Command命令：

bash ssh node_slave erl -detached -noinput -master [email protected]_master -sname [email protected]_slave -s slave slave_start [email protected]_master slave_waiter_0 -setcookie mycookie

這很好解釋了為什麼壓測節點之間需要提前設定SSH免金鑰登入了。

SSH為C/S模式，SSH Server是預設監聽22埠的一個守護程序，等待客戶端傳送命令，解析執行，然後返回結果。明白了這個道理，我們可利用反向Shell機制打造一個SSH替代品。

首先我們需要在一個從節點上啟動一個守護程序：

bash ncat -4 -k -l 39999 -e /bin/bash &

主節點作為客戶端，比如我們想查詢遠端伺服器主機名：

bash echo hostname | ncat 10.77.128.21 39999

一點都不復雜吧，但實際上還有很多的工作要做，比如自動斷開機制等，我已封裝了rsh_client.sh和rsh_daemon.sh兩個檔案，可參考https://github.com/weibomobile/tsung_rsh，不再累述。
問題來了，如何結合Tsung使用呢？

第一步，在所有從機啟動守護程序：

bash sh rsh_daemon.sh start

第二步，需要在Tsung啟動時使用-r引數指定自定義的遠端終端：

bash tsung -r rsh_client.sh -f tsung.xml start

總之，這個SSH終端替代方案，已經在良好的執行在線上實際壓測中了，圖6為其部署結構。

注：其實不僅僅是替代，還可以在其上增加一些資源監控功能，我們已經這樣幹了。

【IP直連特性支援】
Tsung還有一個使用不便的地方，從機必須配置主機名，用於主機啟動從機例項：
程式碼17
在主機名沒有內網DNS解析支援情況下，需要在/etc/hosts檔案中手動配置主機名和IP地址對映關係，若是叢集很大，維護成本高。如何辦呢，我增加了IP直連特性支援：https://github.com/weibomobile/tsung/ ，需要時檢出編譯即可使用。
這樣壓測從機可以直接填寫IP地址：

xml <client weight="1" maxusers="50000" host="client20"> <ip value="10.10.10.20"></ip> </client>

其次，在Tsung啟動時需要指定-I引數，並填寫壓測主機IP地址（可以通過Linux程式碼自動獲取）：

bash tsung -I 壓測主機IP地址 -r rsh_client.sh -f tsung.xml start

這樣改造之後，讓Tsung分散式叢集在複雜網路機房內網環境下適應性向前邁了一大步。

效能壓測流程驅動

壓測之前，我們一般需要關注哪些東西呢，其實大家做法差不多，可以列一個清單：

1. 新增計數器，可以傳送到計數收集伺服器，報表顯示等；
2. 核心邏輯做好日誌記錄，但日誌記錄過多時，可能也會成為瓶頸，需要取捨日誌等級等；
3. 區分核心模組和非核心模組的在資源緊張時是否需要區別對待等。

壓測中，大家一般都是緊密盯著各項報表，檢視伺服器各項資源開銷等。有一點需要強調的是，儘量作為終端使用者一員，親身參與進去，這樣才能夠切身體驗並切切實實感受到此時服務的質量。

壓測後，複查各項報表，檢視錯誤日誌，結合剛才自身的體驗等，認真思考修改問題，然後繼續下一輪壓力測試啦。

小結

如上所述，我們在沒有空閒伺服器情況下因地制宜，充分利用伺服器空閒計算資源執行Tsung（有所增強、修改）分散式壓測叢集，讓整體費用成本接近於零，同時也使之成為一項基礎工具套件，為研發的同學提供足夠多的支援。
在這一利器推動下，保證了我們整個聊天室專案的處理效能能夠按照預期方式向前推進，有時還會有一點小驚喜：
系統處理效能，由專案之初單機服務1萬用戶，優化到單機處理50萬用戶的飛躍；

• 從上線之初服務支援50萬用戶，到後面支援1000萬；
• 專案日常迭代，及時避免並修正了因額外功能引入的系統崩潰隱患；
• 激發了技術創新，期間收穫了3項技術創新專利；
• 勤奮有心的同學，雖然經驗欠缺，但被推著不停的發現問題、思考、解決問題，你可以看到他們成長的軌跡。

雖然看上去這一利器功不可沒，但工具就是工具，關鍵還要看使用的人，是否能夠一直堅持進行下去，是否可以貫穿於整個研發週期；但知易行難，需去除惰性，堅持下去，形成一種習慣，成為日常的業務流程（如圖7）的一個組成部分，否則只能是擺設。

效能壓測驅動

另外，希望能夠給同樣境遇的同學提供一種思路，或受限於SSH不可用而放棄搭建Tsung叢集，或因地制宜需要稍作定製滿足特殊業務，或直接使用我們開源增強版Tsung避免走彎路，或者直接使用Docker等。總之使用Tsung做海量使用者的壓測，它不會讓你失望的。

訂閱諮詢：

• 線上諮詢（QQ）：2251809102
• 電話諮詢：010-64351436
• 更多訊息，歡迎關注“程式設計師編輯部”