前段時(shí)間我們?yōu)槲⒉〢pp增加一個(gè)視頻直播聊天室功能，這是一個(gè)需要支持海量級(jí)手機(jī)終端用戶一起參與、實(shí)時(shí)互動(dòng)的強(qiáng)交互系統(tǒng)，建立在私有協(xié)議之上、有狀態(tài)的長連接TCP應(yīng)用。和其他項(xiàng)目一樣，在立項(xiàng)之初，就已確定所構(gòu)建系統(tǒng)至少能夠承載100萬用戶容量，以及業(yè)務(wù)處理性能最低標(biāo)準(zhǔn)。

　　當(dāng)時(shí)研發(fā)力量投入有限，一名中級(jí)工程師 + 一名初級(jí)工程師，兩人研發(fā)經(jīng)驗(yàn)和實(shí)踐能力的欠缺不足以完成系統(tǒng)容量和處理性能的考核目標(biāo)，這是擺在眼前最為頭疼問題。聊天室業(yè)務(wù)邏輯清晰并已文檔化，倒不用太擔(dān)心功能運(yùn)行正確，除了自我驗(yàn)證外，還會(huì)有QA部門幫忙校驗(yàn)。這驅(qū)使我們?cè)谲浖こ探嵌热ニ伎?，如何通過行之有效的手段或工具去推動(dòng)研發(fā)同學(xué)項(xiàng)目順利完成項(xiàng)目性能考核目標(biāo)。

　　聊天室會(huì)話實(shí)例

　　延伸一下，新項(xiàng)目構(gòu)建之初，自然要關(guān)注總體處理性能目標(biāo)的。但從軟件生命周期角度考慮，還應(yīng)該考慮到系統(tǒng)后續(xù)維護(hù)和迭代。所謂工欲善其事，必先利其器，因此我們需要提供一個(gè)完善的開箱即用、支持海量用戶的性能壓測基礎(chǔ)工具套件，既要能夠保證系統(tǒng)處理性能是可測量的，又要能夠?yàn)槊恳淮伟姹景l(fā)布時(shí)、常規(guī)迭代后再次驗(yàn)證系統(tǒng)性能目標(biāo)。帶著這一目標(biāo)，下面將逐一展開我們?nèi)绾螛?gòu)建百萬用戶性能壓測工具套件的過程以及注意事項(xiàng)。

　　性能貫穿于軟件生命周期

　　性能壓測工具選擇

　　團(tuán)隊(duì)所能夠支配的空閑服務(wù)器數(shù)量幾乎為零，這是現(xiàn)狀。所負(fù)責(zé)業(yè)務(wù)線的大部分服務(wù)器配置為16GB內(nèi)存、24個(gè)CPU核心左右，每時(shí)每刻都在跑著具體的業(yè)務(wù)。若留心觀察，一般晚上九、十點(diǎn)之后資源利用率高，而白天時(shí)間CPU、內(nèi)存、網(wǎng)絡(luò)等資源大概會(huì)剩余30%-60%左右，頗為浪費(fèi)，如何將這部分資源充分利用起來，是一個(gè)需要思索的問題。

　　針對(duì)100萬用戶這樣超大容量壓測需求，要求每臺(tái)壓測機(jī)要能夠負(fù)載盡可能多的用戶量。試想，若一臺(tái)壓測機(jī)器承載1萬用戶，那么就會(huì)需要使用到100臺(tái)，單純所需數(shù)量就是一件讓人很恐怖的事情。

　　若是單獨(dú)為性能壓測申請(qǐng)服務(wù)器資源，一是流程審批流程較為繁冗，二是因?yàn)閴簻y行為不是每時(shí)每刻都會(huì)執(zhí)行高頻事件，會(huì)造成計(jì)算資源極大浪費(fèi)。本著節(jié)約資源理想方式就是充分利用現(xiàn)有的空閑計(jì)算資源用于執(zhí)行性能壓力測試任務(wù)。

　　【眾多選擇】

　　當(dāng)前市面上能夠提供性能壓測的工具很多，選擇面也能很廣泛，下面我將結(jié)合實(shí)際具體業(yè)務(wù)逐一分析和篩選。

　　TcpCopy

　　線上引流模式，針對(duì)新項(xiàng)目或全新功能就不太合適了，業(yè)務(wù)層面若需要一定量的業(yè)務(wù)邏輯支持，很難做得到。

　　JMeter

　　Java編寫，在執(zhí)行1萬個(gè)壓測用戶線程時(shí)，CPU上下文切換頻繁，大量并發(fā)時(shí)會(huì)有內(nèi)存溢出問題，很顯然也不是理想的選擇。

　　nGrinder

　　圖表豐富，架構(gòu)很強(qiáng)大，堆棧依賴項(xiàng)太多，學(xué)習(xí)成本很高。

　　需要額外掌握Python等腳本語言，雖針對(duì)程序員友好，不是所有人都可以馬上修改。

　　數(shù)十個(gè)線程至少占用4GB內(nèi)存，一臺(tái)機(jī)器上要模擬5萬個(gè)用戶，不但CPU上下文切換恐怖，16GB小內(nèi)存機(jī)器更是遠(yuǎn)遠(yuǎn)滿足不了。

　　針對(duì)服務(wù)器資源充足的團(tuán)隊(duì)，可以考慮單獨(dú)機(jī)器部署或Docker部署組成集群，針對(duì)我們團(tuán)隊(duì)情況就不合適了，想免費(fèi)做到是不可能的。

　　Tsung

　　完成同樣性能壓測功能，卻沒有第三方庫依賴，獨(dú)立一套應(yīng)用程序。

　　雖然所測試服務(wù)是I/O密集型，但所占用內(nèi)存不會(huì)成為瓶頸。

　　可能會(huì)觸及到Erlang語言，但我們現(xiàn)在工作用的語言就是Erlang，也就不存在什么問題了。

　　其他

　　綜合所述，Tsung默認(rèn)情況下消耗低，可充分利用現(xiàn)有服務(wù)器空閑計(jì)算資源，線上多次實(shí)踐也證實(shí)資源占用始終在一個(gè)理想可控的范圍內(nèi)，具有可讓百萬用戶壓測執(zhí)行的費(fèi)用成本降低為0的能力，這也是我們選擇Tsung的目的所在。

　　【為什么是Tsung？】

　　Tsung是一個(gè)有著超過15年歷史積累的性能壓測工具，本身受益于Erlang天生支持并發(fā)和分布式以及實(shí)時(shí)性的特性，其進(jìn)程的創(chuàng)建和運(yùn)行非常廉價(jià)，一臺(tái)機(jī)器上輕輕松松創(chuàng)建上百萬個(gè)進(jìn)程。其提供一個(gè)用戶對(duì)應(yīng)一個(gè)進(jìn)程的隔離處理機(jī)制，單機(jī)支持虛擬用戶的用戶數(shù)量可支持若十萬、百萬級(jí)別，只要機(jī)器資源充足（但總體來講受制于受制于網(wǎng)絡(luò)、內(nèi)存等資源，后面會(huì)具體解釋）。單機(jī)計(jì)算能力總是有限的，Tsung的目的就是要把多臺(tái)服務(wù)器橫向擴(kuò)展成分布式集群，從而可以對(duì)外提供一致的海量性能壓力測試服務(wù)。

　　協(xié)議層，Tsung不但支持TCP/UDP/SSL傳輸層協(xié)議等，而且應(yīng)用層協(xié)議，已支持諸如WebDAV/WebScoket/MQTT/MySQL/PGSQL/AQMP/Jabber/XMPP/LDAP等。默認(rèn)情況下，開箱即用，憑借著社區(qū)的支持，市面上能夠找到的公開通用協(xié)議，都有相應(yīng)官方或第三方插件支持。

　　和nGrinder相比，Tsung定位于提供一個(gè)強(qiáng)大的性能測試工具，在易用性和強(qiáng)大可擴(kuò)展方面保持了一個(gè)平衡點(diǎn)?；赬ML + DSL提供可配置、可編程的能力。比如我們可設(shè)置上一次的響應(yīng)結(jié)果作為下一次請(qǐng)求內(nèi)容，我們可配置多種業(yè)務(wù)協(xié)議、多個(gè)業(yè)務(wù)場景作為一個(gè)整體壓測等。盡力抽象所要壓測的情景吧，你不會(huì)失望的。

相關(guān)電子資料下載