高速增長(zhǎng)的互聯(lián)網(wǎng)業(yè)務(wù)要求產(chǎn)品開發(fā)、迭代和交付周期越來(lái)越短，而IT基礎(chǔ)設(shè)施的廣泛云化和第三方API接口的大量使用，使傳統(tǒng)的基于內(nèi)部環(huán)境搭建的壓力測(cè)試方法和測(cè)試工具越來(lái)越難以滿足應(yīng)用功能可用和容量規(guī)劃預(yù)估的需求。
企業(yè)該如何為頻繁的市場(chǎng)活動(dòng)和產(chǎn)品快速迭代進(jìn)行有效而準(zhǔn)確的壓力測(cè)試呢？希望通過(guò)云端壓力測(cè)試專家，云智慧壓測(cè)寶產(chǎn)品總監(jiān)陸興海分享的兩個(gè)客戶案例，為企業(yè)的云端壓力測(cè)試和業(yè)務(wù)容量規(guī)劃帶來(lái)一些有價(jià)值的參考。
壓測(cè)寶云壓測(cè)客戶案例1：壓測(cè)寶如何做業(yè)務(wù)容量的測(cè)試與規(guī)劃？
云智慧有個(gè)做旅游和攝影服務(wù)平臺(tái)的客戶要舉辦一次活動(dòng)，為本次活動(dòng)制作了專門的活動(dòng)頁(yè)面，在活動(dòng)頁(yè)面用戶可以報(bào)名。那么在短時(shí)間內(nèi)系統(tǒng)到底能撐得住多大的用戶并發(fā)？
這是活動(dòng)運(yùn)營(yíng)和技術(shù)部門必須提前考慮的問(wèn)題，因?yàn)樵谌ツ昱e辦類似活動(dòng)時(shí)就出現(xiàn)了用戶大量涌入導(dǎo)致服務(wù)不可用的狀況，所以首先要幫助用戶整理容量測(cè)試和規(guī)劃的工作思路。
具體該如何實(shí)施壓測(cè)呢，這里劃分了幾個(gè)環(huán)節(jié)：
［1］場(chǎng)景確定與壓測(cè)腳本準(zhǔn)備
用戶在注冊(cè)時(shí)需要提交用戶的姓名、手機(jī)號(hào)和手機(jī)驗(yàn)證碼，之后提交申請(qǐng)即可，所以實(shí)際上用戶申請(qǐng)注冊(cè)只調(diào)用了一個(gè)API接口來(lái)完成，這是一個(gè)比較簡(jiǎn)單的場(chǎng)景。
1、因?yàn)樯婕暗绞謾C(jī)驗(yàn)證場(chǎng)景，在不提供對(duì)應(yīng)API的情況下，建議用戶使用萬(wàn)能的驗(yàn)證碼或者暫時(shí)取消驗(yàn)證碼；
2、是否允許多個(gè)手機(jī)號(hào)同時(shí)注冊(cè)，如果允許我們可用使用固定參數(shù)傳遞，如果不允許，我們可準(zhǔn)備對(duì)應(yīng)手機(jī)號(hào)的測(cè)試數(shù)據(jù)來(lái)應(yīng)對(duì)；
3、短時(shí)間內(nèi)發(fā)起大量并發(fā)，用戶本身是否有安全擋板，如果有，需要把施壓節(jié)點(diǎn)的IP加入白名單；
［2］施壓模式
既然是容量探測(cè)，所以整體的施壓過(guò)程是一個(gè)梯度漸進(jìn)的過(guò)程，一般不會(huì)上來(lái)就是一條直線。這是一直和用戶強(qiáng)調(diào)的問(wèn)題，壓測(cè)的目的絕對(duì)不是把系統(tǒng)壓垮，壓測(cè)的目的是通過(guò)不斷增加的并發(fā)來(lái)客觀評(píng)估系統(tǒng)在不同的壓力條件下的性能狀況；基于此我們定制了施壓的梯度壓力模式，如圖所示：
［3］壓測(cè)點(diǎn)分布
傳統(tǒng)壓力測(cè)試工具主要在內(nèi)網(wǎng)產(chǎn)生壓力，壓力的規(guī)模受限于物理機(jī)器及License數(shù)量，造成準(zhǔn)備周期長(zhǎng)及成本高等問(wèn)題。而云壓測(cè)提供可靠的分布式壓測(cè)服務(wù)器（壓測(cè)點(diǎn)），充分利用云端的計(jì)算資源，從而突破了這個(gè)限制。
目前云智慧的壓測(cè)點(diǎn)來(lái)自云服務(wù)的云主機(jī)（AWS、Ucloud和阿里云等）以及云智慧部署在全國(guó)各大IDC核心機(jī)房的服務(wù)器，目前主要提供的區(qū)域如下圖所示：
［4］壓測(cè)時(shí)間設(shè)定
根據(jù)系統(tǒng)訪問(wèn)情況，一般會(huì)建議用戶在凌晨進(jìn)行壓測(cè)，此時(shí)能夠保證對(duì)用戶的影響最小，也能保證正常用戶訪問(wèn)對(duì)壓測(cè)結(jié)果的干擾最小。但這個(gè)壓測(cè)時(shí)間設(shè)定不是絕對(duì)的，需要與具體用戶的業(yè)務(wù)場(chǎng)景結(jié)合判斷。
［5］壓測(cè)數(shù)據(jù)分析
在基本的參數(shù)確定之后，就可用根據(jù)預(yù)定的時(shí)間來(lái)執(zhí)行壓測(cè)任務(wù)了，云壓測(cè)能夠進(jìn)行秒級(jí)的數(shù)據(jù)采集和實(shí)時(shí)統(tǒng)計(jì)分析，能夠隨時(shí)調(diào)整壓力。隨著壓力的逐步上升，能夠動(dòng)態(tài)呈現(xiàn)系統(tǒng)的性能數(shù)據(jù)。在逐步加壓的過(guò)程中，如果性能急劇下降或大量出錯(cuò)，就沒(méi)有必要繼續(xù)執(zhí)行壓測(cè)任務(wù)，此時(shí)可以終止任務(wù)，也可以下調(diào)壓力，確保對(duì)整個(gè)壓測(cè)過(guò)程的把控。
針對(duì)這個(gè)用戶，按照上述步驟實(shí)施壓力測(cè)試之后，通過(guò)相關(guān)測(cè)試結(jié)果的數(shù)據(jù)分析和評(píng)估，得到了壓測(cè)結(jié)論如下：
被壓測(cè)的注冊(cè)接口在360并發(fā)用戶以下時(shí)表現(xiàn)相對(duì)良好，在并發(fā)用戶達(dá)到360至500時(shí)性能欠佳，說(shuō)的更直接一點(diǎn)就是：該系統(tǒng)能夠支撐360的并發(fā)，具體論證如下：
1、并發(fā)達(dá)到360之后失敗明顯增多并且持續(xù)到任務(wù)結(jié)束；
2、并發(fā)達(dá)到420之后，響應(yīng)時(shí)間超出3000ms標(biāo)準(zhǔn)值且持續(xù)到最后；
3、每秒鐘事務(wù)數(shù)（TPS）穩(wěn)定在130左右，表現(xiàn)比較良好；
本次壓測(cè)的概要數(shù)據(jù)如下圖所示：
壓測(cè)寶云壓測(cè)客戶案例2：基于壓測(cè)的后端性能問(wèn)題分析與定位
下面介紹另外一個(gè)用戶的真實(shí)需求場(chǎng)景，這里著重分析用戶在壓測(cè)時(shí)遇到的性能問(wèn)題，主要從失敗和響應(yīng)時(shí)間緩慢兩個(gè)角度，首先是失敗情況，如下圖所示，失敗的類型及其占比。
在整個(gè)測(cè)試過(guò)程系統(tǒng)從5:05分開始出現(xiàn)逐漸增加的不同類型服務(wù)器處理錯(cuò)誤，導(dǎo)致事務(wù)處理失敗，具體錯(cuò)誤信息如下：
502：錯(cuò)誤網(wǎng)關(guān)（從5:43～5:46共出現(xiàn)112次502錯(cuò)誤）；
600：connection連接異常，從5:05～5:50共出現(xiàn)264次600錯(cuò)誤）；
601：Socket異常（5:31和5:47出現(xiàn)2次601錯(cuò)誤）；
603：拒接服務(wù)錯(cuò)誤（從5:21至5:49共出現(xiàn)48次603錯(cuò)誤）；
其實(shí)是響應(yīng)時(shí)間分析，如下圖所示某個(gè)事務(wù)及其對(duì)應(yīng)的請(qǐng)求情況。
從上圖可以看出“好友動(dòng)態(tài)”的平均事務(wù)請(qǐng)求響應(yīng)時(shí)間為10,862ms，是其他應(yīng)用請(qǐng)求的平均響應(yīng)時(shí)間的7倍（其他請(qǐng)求平均響應(yīng)時(shí)間為1,400ms）。
上圖為從壓測(cè)寶系統(tǒng)獲取的一次好友動(dòng)態(tài)事務(wù)請(qǐng)求響應(yīng)日志，可以看出響應(yīng)時(shí)間為12232ms，其中連接時(shí)間為3136ms，請(qǐng)求返回的內(nèi)容非常大（51764Bytes）。和其他應(yīng)用相比好友動(dòng)態(tài)應(yīng)用耗時(shí)非常長(zhǎng)，用戶體驗(yàn)很差。
在本次壓測(cè)的全程，基于云智慧的應(yīng)用性能管理產(chǎn)品透視寶來(lái)進(jìn)一步分析后端性能情況，通過(guò)后端應(yīng)用請(qǐng)求分析可以查看一段時(shí)間內(nèi)Web應(yīng)用處理事務(wù)請(qǐng)求的響應(yīng)時(shí)間、請(qǐng)求數(shù)及詳細(xì)的請(qǐng)求信息及變化趨勢(shì)。在并發(fā)用戶超過(guò)200時(shí)響應(yīng)時(shí)間明顯變慢，但整體系統(tǒng)響應(yīng)時(shí)間表現(xiàn)正常（處理時(shí)間小于500ms占比74.13%）；
接著我們利用透視寶的代碼級(jí)堆棧定位分析功能來(lái)進(jìn)一步分析數(shù)據(jù)庫(kù)SQL情況，如下圖所示。
通過(guò)后端關(guān)鍵事務(wù)快照可以看出單次請(qǐng)求處理的數(shù)據(jù)庫(kù)連接耗時(shí)1400.92ms，占比95.23%（總響應(yīng)時(shí)間1471.02ms），是主要的數(shù)據(jù)庫(kù)耗時(shí)來(lái)源；
可以看出數(shù)據(jù)庫(kù)查詢操作耗時(shí)占比3.71%，是數(shù)據(jù)庫(kù)第二耗時(shí)來(lái)源；而且多個(gè)數(shù)據(jù)庫(kù)查詢SQL語(yǔ)句大部分查詢條件相同，在高并發(fā)量用戶查詢時(shí)有較大的性能優(yōu)化空間。
基于以上的分析，建議用戶從如下方面進(jìn)行優(yōu)化：
1）如果應(yīng)用處理入口有前置負(fù)載均衡服務(wù)器，建議對(duì)負(fù)載均衡服務(wù)器相關(guān)參數(shù)進(jìn)行優(yōu)化，提升用戶請(qǐng)求入口處理能力；同時(shí)建議對(duì)負(fù)載均衡服務(wù)器進(jìn)行性能監(jiān)控，及時(shí)發(fā)現(xiàn)系統(tǒng)瓶頸；
2）事務(wù)請(qǐng)求處理過(guò)程中數(shù)據(jù)庫(kù)連接耗時(shí)較長(zhǎng)，建議采用數(shù)據(jù)庫(kù)連接池組件進(jìn)行性能優(yōu)化；
3）建議在系統(tǒng)架構(gòu)中增加數(shù)據(jù)庫(kù)緩存，同時(shí)對(duì)類似的SQL操作進(jìn)行處理優(yōu)化，以減少后端數(shù)據(jù)庫(kù)的連接次數(shù)，提高數(shù)據(jù)庫(kù)查詢效率和性能；
基于請(qǐng)求的深入分析，在壓測(cè)寶中提供問(wèn)題請(qǐng)求的詳細(xì)快照，包括請(qǐng)求的響應(yīng)時(shí)間分解、請(qǐng)求頭和返回結(jié)果，如下圖所示。
另外如上面所示，在壓測(cè)寶的單次請(qǐng)求追蹤部分集成了性能管理產(chǎn)品透視寶，能夠通過(guò)單次請(qǐng)求直接查看后端的代碼問(wèn)題，如下圖所示：
通過(guò)對(duì)失敗、緩慢與錯(cuò)誤的事務(wù)與請(qǐng)求進(jìn)行細(xì)化分析，包括對(duì)錯(cuò)誤類型分析、請(qǐng)求快照查看以及后端深入定位。
以上是兩個(gè)真實(shí)應(yīng)用場(chǎng)景的云端壓力測(cè)試分析案例，通過(guò)性能壓力測(cè)試（壓測(cè)寶）我們可以清楚的知曉業(yè)務(wù)容量規(guī)劃，并發(fā)現(xiàn)系統(tǒng)中影響業(yè)務(wù)的性能問(wèn)題（請(qǐng)求緩慢、失?。?。通過(guò)與應(yīng)用性能管理（透視寶）集成來(lái)定位和診斷根源問(wèn)題，深入分析后端的性能瓶頸來(lái)提升業(yè)務(wù)質(zhì)量，從而實(shí)現(xiàn)應(yīng)用的快速優(yōu)化和上線。
?q?????(??(
