云智慧產(chǎn)品總監(jiān) 陸興海

　　高速增長的互聯(lián)網(wǎng)業(yè)務(wù)要求產(chǎn)品開發(fā)、迭代和交付周期越來越短，而IT基礎(chǔ)設(shè)施的廣泛云化和第三方API接口的大量使用，使傳統(tǒng)的基于內(nèi)部環(huán)境搭建的壓力測試方法和測試工具越來越難以滿足應(yīng)用功能可用和容量規(guī)劃預(yù)估的需求。

　　企業(yè)該如何為頻繁的市場活動(dòng)和產(chǎn)品快速迭代進(jìn)行有效而準(zhǔn)確的壓力測試呢?希望通過云端壓力測試專家，云智慧壓測寶產(chǎn)品總監(jiān)陸興海分享的兩個(gè)客戶案例，為企業(yè)的云端壓力測試和業(yè)務(wù)容量規(guī)劃帶來一些有價(jià)值的參考。

　　壓測寶云壓測客戶案例1：壓測寶如何做業(yè)務(wù)容量的測試與規(guī)劃?

　　云智慧有個(gè)做旅游和攝影服務(wù)平臺(tái)的客戶要舉辦一次活動(dòng)，為本次活動(dòng)制作了專門的活動(dòng)頁面，在活動(dòng)頁面用戶可以報(bào)名。那么在短時(shí)間內(nèi)系統(tǒng)到底能撐得住多大的用戶并發(fā)?

　　

　　這是活動(dòng)運(yùn)營和技術(shù)部門必須提前考慮的問題，因?yàn)樵谌ツ昱e辦類似活動(dòng)時(shí)就出現(xiàn)了用戶大量涌入導(dǎo)致服務(wù)不可用的狀況，所以首先要幫助用戶整理容量測試和規(guī)劃的工作思路。

　　具體該如何實(shí)施壓測呢，這里劃分了幾個(gè)環(huán)節(jié)：

　　[1]場景確定與壓測腳本準(zhǔn)備

　　用戶在注冊時(shí)需要提交用戶的姓名、手機(jī)號和手機(jī)驗(yàn)證碼，之后提交申請即可，所以實(shí)際上用戶申請注冊只調(diào)用了一個(gè)API接口來完成，這是一個(gè)比較簡單的場景。

　　1、因?yàn)樯婕暗绞謾C(jī)驗(yàn)證場景，在不提供對應(yīng)API的情況下，建議用戶使用萬能的驗(yàn)證碼或者暫時(shí)取消驗(yàn)證碼;

　　2、是否允許多個(gè)手機(jī)號同時(shí)注冊，如果允許我們可用使用固定參數(shù)傳遞，如果不允許，我們可準(zhǔn)備對應(yīng)手機(jī)號的測試數(shù)據(jù)來應(yīng)對;

　　3、短時(shí)間內(nèi)發(fā)起大量并發(fā)，用戶本身是否有安全擋板，如果有，需要把施壓節(jié)點(diǎn)的IP加入白名單;

　　[2]施壓模式

　　既然是容量探測，所以整體的施壓過程是一個(gè)梯度漸進(jìn)的過程，一般不會(huì)上來就是一條直線。這是一直和用戶強(qiáng)調(diào)的問題，壓測的目的絕對不是把系統(tǒng)壓垮，壓測的目的是通過不斷增加的并發(fā)來客觀評估系統(tǒng)在不同的壓力條件下的性能狀況;基于此我們定制了施壓的梯度壓力模式，如圖所示：

　　

　　

　　[3]壓測點(diǎn)分布

　　傳統(tǒng)壓力測試工具主要在內(nèi)網(wǎng)產(chǎn)生壓力，壓力的規(guī)模受限于物理機(jī)器及License數(shù)量，造成準(zhǔn)備周期長及成本高等問題。而云壓測提供可靠的分布式壓測服務(wù)器(壓測點(diǎn))，充分利用云端的計(jì)算資源，從而突破了這個(gè)限制。

　　目前云智慧的壓測點(diǎn)來自云服務(wù)的云主機(jī)(AWS、Ucloud和阿里云等)以及云智慧部署在全國各大IDC核心機(jī)房的服務(wù)器，目前主要提供的區(qū)域如下圖所示：

　　

　　[4]壓測時(shí)間設(shè)定

　　根據(jù)系統(tǒng)訪問情況，一般會(huì)建議用戶在凌晨進(jìn)行壓測，此時(shí)能夠保證對用戶的影響最小，也能保證正常用戶訪問對壓測結(jié)果的干擾最小。但這個(gè)壓測時(shí)間設(shè)定不是絕對的，需要與具體用戶的業(yè)務(wù)場景結(jié)合判斷。

　　[5]壓測數(shù)據(jù)分析

　　在基本的參數(shù)確定之后，就可用根據(jù)預(yù)定的時(shí)間來執(zhí)行壓測任務(wù)了，云壓測能夠進(jìn)行秒級的數(shù)據(jù)采集和實(shí)時(shí)統(tǒng)計(jì)分析，能夠隨時(shí)調(diào)整壓力。隨著壓力的逐步上升，能夠動(dòng)態(tài)呈現(xiàn)系統(tǒng)的性能數(shù)據(jù)。在逐步加壓的過程中，如果性能急劇下降或大量出錯(cuò)，就沒有必要繼續(xù)執(zhí)行壓測任務(wù)，此時(shí)可以終止任務(wù)，也可以下調(diào)壓力，確保對整個(gè)壓測過程的把控。

　　針對這個(gè)用戶，按照上述步驟實(shí)施壓力測試之后，通過相關(guān)測試結(jié)果的數(shù)據(jù)分析和評估，得到了壓測結(jié)論如下：

　　被壓測的注冊接口在360并發(fā)用戶以下時(shí)表現(xiàn)相對良好，在并發(fā)用戶達(dá)到360至500時(shí)性能欠佳，說的更直接一點(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)比較良好;

　　本次壓測的概要數(shù)據(jù)如下圖所示：

　　

　　壓力測試綜合報(bào)表如下圖所示，當(dāng)并發(fā)用戶數(shù)達(dá)到360時(shí)，系統(tǒng)開始出現(xiàn)了大面積失敗(280時(shí)出現(xiàn)了1次錯(cuò)誤)，并且失敗問題持續(xù)到壓測結(jié)束都沒有改善，不過整個(gè)測試過程中并沒有出現(xiàn)斷言不匹配的情況，即正確性保持良好。

　　

　　事務(wù)響應(yīng)時(shí)間趨勢：隨著應(yīng)用訪問用戶量增加，在并發(fā)用戶達(dá)到420的時(shí)候，系統(tǒng)事務(wù)處理的時(shí)間也顯著上升(大于參考標(biāo)準(zhǔn)3000ms)，且響應(yīng)時(shí)間在以后一直沒有下降。

　　

　　事務(wù)處理性能趨勢：當(dāng)壓力穩(wěn)步上升后，應(yīng)用事務(wù)處理能力保持平穩(wěn)，基本維持在每秒鐘處理130個(gè)左右事務(wù)，該數(shù)值基本能保障并發(fā)用戶注冊的需求。

　　壓測寶云壓測客戶案例2：基于壓測的后端性能問題分析與定位

　　下面介紹另外一個(gè)用戶的真實(shí)需求場景，這里著重分析用戶在壓測時(shí)遇到的性能問題，主要從失敗和響應(yīng)時(shí)間緩慢兩個(gè)角度，首先是失敗情況，如下圖所示，失敗的類型及其占比。

　　

　　在整個(gè)測試過程系統(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ù)及其對應(yīng)的請求情況。

　　

　　從上圖可以看出“好友動(dòng)態(tài)”的平均事務(wù)請求響應(yīng)時(shí)間為10,862ms，是其他應(yīng)用請求的平均響應(yīng)時(shí)間的7倍(其他請求平均響應(yīng)時(shí)間為1,400ms)。

　　

　　上圖為從壓測寶系統(tǒng)獲取的一次好友動(dòng)態(tài)事務(wù)請求響應(yīng)日志，可以看出響應(yīng)時(shí)間為12232ms，其中連接時(shí)間為3136ms，請求返回的內(nèi)容非常大(51764Bytes)。和其他應(yīng)用相比好友動(dòng)態(tài)應(yīng)用耗時(shí)非常長，用戶體驗(yàn)很差。

　　在本次壓測的全程，基于云智慧的應(yīng)用性能管理產(chǎn)品透視寶來進(jìn)一步分析后端性能情況，通過后端應(yīng)用請求分析可以查看一段時(shí)間內(nèi)Web應(yīng)用處理事務(wù)請求的響應(yīng)時(shí)間、請求數(shù)及詳細(xì)的請求信息及變化趨勢。在并發(fā)用戶超過200時(shí)響應(yīng)時(shí)間明顯變慢，但整體系統(tǒng)響應(yīng)時(shí)間表現(xiàn)正常(處理時(shí)間小于500ms占比74.13%);

　　

　　接著我們利用透視寶的代碼級堆棧定位分析功能來進(jìn)一步分析數(shù)據(jù)庫SQL情況，如下圖所示。

　　

　　通過后端關(guān)鍵事務(wù)快照可以看出單次請求處理的數(shù)據(jù)庫連接耗時(shí)1400.92ms，占比95.23%(總響應(yīng)時(shí)間1471.02ms)，是主要的數(shù)據(jù)庫耗時(shí)來源;

　　

　　

　　可以看出數(shù)據(jù)庫查詢操作耗時(shí)占比3.71%，是數(shù)據(jù)庫第二耗時(shí)來源;而且多個(gè)數(shù)據(jù)庫查詢SQL語句大部分查詢條件相同，在高并發(fā)量用戶查詢時(shí)有較大的性能優(yōu)化空間。

　　基于以上的分析，建議用戶從如下方面進(jìn)行優(yōu)化：

　　1)如果應(yīng)用處理入口有前置負(fù)載均衡服務(wù)器，建議對負(fù)載均衡服務(wù)器相關(guān)參數(shù)進(jìn)行優(yōu)化，提升用戶請求入口處理能力;同時(shí)建議對負(fù)載均衡服務(wù)器進(jìn)行性能監(jiān)控，及時(shí)發(fā)現(xiàn)系統(tǒng)瓶頸;

　　2)事務(wù)請求處理過程中數(shù)據(jù)庫連接耗時(shí)較長，建議采用數(shù)據(jù)庫連接池組件進(jìn)行性能優(yōu)化;

　　3)建議在系統(tǒng)架構(gòu)中增加數(shù)據(jù)庫緩存，同時(shí)對類似的SQL操作進(jìn)行處理優(yōu)化，以減少后端數(shù)據(jù)庫的連接次數(shù)，提高數(shù)據(jù)庫查詢效率和性能;

　　基于請求的深入分析，在壓測寶中提供問題請求的詳細(xì)快照，包括請求的響應(yīng)時(shí)間分解、請求頭和返回結(jié)果，如下圖所示。

　　

　　另外如上面所示，在壓測寶的單次請求追蹤部分集成了性能管理產(chǎn)品透視寶，能夠通過單次請求直接查看后端的代碼問題，如下圖所示：

　　

　　通過對失敗、緩慢與錯(cuò)誤的事務(wù)與請求進(jìn)行細(xì)化分析，包括對錯(cuò)誤類型分析、請求快照查看以及后端深入定位。

　　以上是兩個(gè)真實(shí)應(yīng)用場景的云端壓力測試分析案例，通過性能壓力測試(壓測寶)我們可以清楚的知曉業(yè)務(wù)容量規(guī)劃，并發(fā)現(xiàn)系統(tǒng)中影響業(yè)務(wù)的性能問題(請求緩慢、失敗)。通過與應(yīng)用性能管理(透視寶)集成來定位和診斷根源問題，深入分析后端的性能瓶頸來提升業(yè)務(wù)質(zhì)量，從而實(shí)現(xiàn)應(yīng)用的快速優(yōu)化和上線。