接上篇：微信小程序性能測試之jmeter踩坑記錄（一），經過前面大半個月的摸魚，流程是走了一遍，但結果好像沒那么清晰，也沒有具體的解決方案，日子在逼近，加上運營的催促，於是老大親自主導，考慮到我們的經驗不足，決定引入外援。
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
經歷過幾天的討論風聲后，敲定了一個合作方，並發來了一個需求調研文檔，並表示后面會陸續派人過來對接。
需求調研文檔包括，需求目標以及現有系統架構圖。比起我們模糊的定義，他們僅用了一句話就概括了目標：活動預計會達到50w用戶的同時登錄下單操作，所以需要系統能夠承受住50W的並發，其中登錄50w並發，下單轉化率3%為1.5W並發。
典型的系統架構如下：
確認后合作方先派人過來熟悉項目了，不久便出了一個測試計划，包括每個階段以及對應的測試時間與負責人。
測試工具開發—測試環境准備—中間件壓測—單機壓測—新生產環境准備—確定新生產環境預算—新生產環境切換—所有測試工作完成—測試報告+建議—新生產環境中間件升級—高性能新生產環境試運行—redis數據同步至mysql—生產系統回切
計划壓力測試分為中間件壓力測試，線性壓力測試，單機壓力測試三個輪次，由於本地沒有測試環境，直接在阿里雲申請服務器並搭建測試，記錄如下：
中間件壓力測試
中間件輪次主要測試系統的各種中間件是否能承受住目標並發的壓力，包括Rds，Redis，SLB，可簡單分為以下三步。
第一步：進行壓測腳本開發，模擬后台程序產生業務壓力，對redis和Rds（mysql）進行請求，以達到用最少的硬件資源在最少的時間內處理最多的請求的目的。
第二步：進行壓測環境搭建，壓測工具為apache benchmark，分別部署在16台阿里ecs服務器組成的集群（集群a）里，模擬后台的壓測腳本被部署在另外16台用相同規格的ecs組成的集群（集群b）里，集群b由一個負載均衡slb平均分配壓力
第三步：進行壓力測試，並統計ab壓測的rps（request per second 每秒處理請求數 即並發數）等結果，通過計算rps即可看到目標並發數下的redis和rds中間件的負載等參數，便可分析中間件是否能承受目標壓力
時間計划（略）
中間件測試案例如下：
| 場景 |
目標 |
案例 |
| Redis |
單次登錄寫入的緩存大小 |
清空Redis緩存，前端登錄，查看Redis緩存大小 |
| 單次下單業務寫入的緩存大小 |
清空Redis緩存，前端操作完成一次下單業務，查看Redis緩存大小 |
|
| 連接數 |
登錄rps壓力50W+訂單rps壓力1.5W，Redis連接數 |
|
| 帶寬 |
登錄rps壓力50W+訂單rps壓力1.5W，Redis帶寬 |
|
| QPS |
登錄rps壓力50W+訂單rps壓力1.5W，Redis QPS |
|
| CPU |
登錄rps壓力50W+訂單rps壓力1.5W，Redis CPU使用率 |
|
| MySql |
連接數 |
登錄rps壓力50W+訂單rps壓力1.5W，MySql 連接數 |
| 帶寬 |
登錄rps壓力50W+訂單rps壓力1.5W，MySql 帶寬 |
|
| IOPS |
登錄rps壓力50W+訂單rps壓力1.5W，MySql IOPS |
|
| CPU |
登錄rps壓力50W+訂單rps壓力1.5W，MySql CPU使用率 |
RDS（MySQL）測試結果
本次測試的RDS為60核頂配版，測試時，使用了2台A機和2台B機。其中1台A機發送的命令如下圖所示：
可知1台A機會開4個線程，對應1台B機發送壓力請求，故2台A機共8個線程對應2台B機發送壓力。下圖是某1個線程的壓力測試結果：
圖中的Request per second代表並發數，該圖表示該線程的測試結果並發數為1422。經統計，8個線程的並發數平均值為1400，故此次測試系統總並發數為8*1400=11200。
同時查看系統資源負載情況（圖略），RDS的CPU使用率接近40%，空閑CPU充裕。會話連接數為641，而該RDS的最大連接數為100000。IOPS為501，而該RDS的最大IOPS為50000。TPS/QPS為57139，QPS代表每秒執行的查詢次數，而本次測試1次請求並發需要執行4次查詢，故RDS顯示的QPS計算可得知並發數為57139/4=14284，與AB壓力測試工具的結果11200接近。
綜上所述，在系統下訂單時並發數達到1.1~1.4萬的時候，RDS的QPS為4.4~5.6萬，RDS的各項硬件負荷正常，RDS運轉正常，完全可以應對下訂單時的1.5萬並發需求。
Redis（集群）測試結果
本次測試的Redis為256G集群版，測試時，使用了16台A機和16台B機。其中1台A機發送的命令如下圖所示：
由上圖可知1台A機對應1台B機同時使用4個線程發送壓力請求。下圖是某1個線程的壓力請求結果：
由上圖可以看出Request per second 即並發數為5850，經過數據的統計得出16台A機，每台A機4個線程，共16*4=64個線程的平均RPS為5850，故本次測試的總並發數為64*5850=374400。
下圖是Redis在系統37.44萬並發時的各項硬件指標：
注意到上圖其余指標正常，而CPU占用率已經達到了90%。
綜上所述，在系統登錄並發達到37.44萬時，256G集群版本的Redis的CPU已經達到極限，考慮到登錄的目標並發數為50萬，故該版本的Redis暫不能支撐如此高的並發，推薦使用512G集群版甚至1T集群版的Redis更為穩妥。
SLB（負載均衡）測試結果
本次測試采用的負載均衡規格為slb.s3.large，最大連接數為1000000，最大CPS為100000，最大QPS為50000，最大外網帶寬為5120Mbps。
測試時，模擬了流量最大的接口。
1台A機同樣采用了4線程發起壓力，下圖是其中1條線程的壓力結果：
由上圖可知Request per second即並發數為5245，經統計所有測試結果計算后得出RPS平均數為5240。
本次SLB測試采用了分階梯測試，分別采用1台，2台，4台，8台，16台A機發起壓力測試，並統計分析測試結果。
同時查看SLB流入流量情況（圖略），分析可知，SLB的帶寬占用隨着A機的數量呈線性增長，其比例大致為帶寬占用為A機數量*100Mbps。而1台A機的RPS為5240*4=20960，如果要達到50萬的RPS，則需要的A機台數為500000/20960=23.85台，即24台，則SLB帶寬為24*100=2400Mbps。該次測試用的SLB最大帶寬為5120Mbps，故當系統達到50萬並發時，負載均衡SLB帶寬占用僅使用一半不到，完全滿足目標的需求。
中間件測試結果總覽
注意：由於測試設備有限（未買到512G以上的Redis），以下均為登錄33萬並發，訂單1.5萬並發的測試結果數據
| 場景 |
目標 |
案例 |
結果 |
| Redis |
單次登錄寫入的緩存大小 |
清空Redis緩存，前端登錄，查看Redis緩存大小 |
7.08Mb/1w |
| 單次下單業務寫入的緩存大小 |
清空Redis緩存，前端操作完成一次下單業務，查看Redis緩存大小 |
(formId 1.77Mb/1w) |
|
| 連接數 |
登錄rps壓力33W+訂單rps壓力1.5W，Redis連接數 |
|
|
| 帶寬 |
登錄rps壓力33W+訂單rps壓力1.5W，Redis帶寬 |
流入56.9M，74.5M流出 |
|
| QPS |
登錄rps壓力33W+訂單rps壓力1.5W，Redis QPS |
701722 |
|
| CPU |
登錄rps壓力33W+訂單rps壓力1.5W，Redis CPU使用率 |
90.2% |
|
| MySql |
連接數 |
登錄rps壓力33W+訂單rps壓力1.5W，MySql 連接數 |
587 |
| 帶寬 |
登錄rps壓力33W+訂單rps壓力1.5W，MySql 帶寬 |
流入35.1M，流出52.8M |
|
| IOPS |
登錄rps壓力33W+訂單rps壓力1.5W，MySql IOPS |
501 |
|
| CPU |
登錄rps壓力33W+訂單rps壓力1.5W，MySql CPU使用率 |
37% |
本次對中間件的壓力測試結果數據分析表明：當使用slb.s3.large版負載均衡時，能承受住50萬並發的流量沖擊。當使用60核頂配RDS（MySQL）數據庫時，能承受住1.5萬的訂單並發壓力。當使用256G的Redis集群版時，登錄場景最多能承受住33萬左右的並發壓力，推薦使用512G以上的Redis配置
---------------------------------------------------------------------------------------未完待續-------------------------------------------------------------------------------