阿里云-性能測(cè)試服務(wù)最佳實(shí)踐-D

1、性能測(cè)試最佳實(shí)踐批量計(jì)算/周邊工具批量計(jì)算/周邊工具 PAGE 25 PAGE 25最佳實(shí)踐訪問(wèn)性能測(cè)試控制臺(tái)門戶類網(wǎng)站性能測(cè)試分析及調(diào)優(yōu)背景前段時(shí)間，性能測(cè)試團(tuán)隊(duì)經(jīng)歷了一個(gè)規(guī)模較大的門戶網(wǎng)站的性能優(yōu)化工作，該網(wǎng)站的開(kāi)發(fā)和合作涉及多個(gè)組織 和部門，而且網(wǎng)站的重要性不言而喻，同時(shí)上線時(shí)間非常緊迫，關(guān)注度也很高，所以對(duì)于整個(gè)團(tuán)隊(duì)的壓力也非 常大。在此，把整個(gè)經(jīng)歷過(guò)程給大家分享一下，包括了主要包括了如何使用性能測(cè)試的壓測(cè)工具，壓測(cè)前的性能問(wèn)題 評(píng)估，以及壓測(cè)執(zhí)行后的性能問(wèn)題分析、瓶頸定位。該門戶網(wǎng)站的服務(wù)器是放在華通和阿里云的平臺(tái)上的，所以對(duì)華通和阿里共建的云平臺(tái)安全及應(yīng)急措施方面要 求非常高，需要

2、團(tuán)隊(duì)給予全力的保障和配合。性能測(cè)試（Performance Testing）是集測(cè)試機(jī)管理、測(cè)試腳本管理、測(cè)試場(chǎng)景管理、測(cè)試任務(wù)管理、測(cè)試結(jié)果管理為一體的性能云測(cè)試平臺(tái)，可以幫助您全方位的評(píng)估云上系統(tǒng)性能。本次優(yōu)化主要是使用了該測(cè)試平臺(tái)服務(wù)對(duì)客戶搭建在ECS上的服務(wù)器進(jìn)行多種類型（性能測(cè)試、負(fù)載測(cè)試、壓 力測(cè)試、穩(wěn)定性測(cè)試、混合場(chǎng)景測(cè)試、異常測(cè)試等）的性能壓測(cè)、調(diào)試和分析，最終達(dá)到滿足期望預(yù)估的性能 目標(biāo)值，且上線后在高峰期滿足實(shí)際的性能和穩(wěn)定要求。術(shù)語(yǔ)定義在介紹項(xiàng)目經(jīng)歷之前，再明確一下測(cè)試當(dāng)中用到的專業(yè)指標(biāo)術(shù)語(yǔ)定義，包括但不僅限于以下：PV: 即PageView, 即頁(yè)面瀏覽量或點(diǎn)擊量，用戶

3、每次刷新即被計(jì)算一次。我們可以認(rèn)為，用戶的一次刷新，給服務(wù)器造成了一次請(qǐng)求。UV: 即UniqueVisitor,訪問(wèn)您網(wǎng)站的一臺(tái)電腦客戶端為一個(gè)訪客。00:00-24:00內(nèi)相同的客戶端只被計(jì)算一次。TPS:TPS(Transaction Per Second)每秒鐘系統(tǒng)能夠處理的交易或事務(wù)的數(shù)量，它是衡量系統(tǒng)處理能力的重要指標(biāo)。響應(yīng)時(shí)間: 響應(yīng)時(shí)間是指從客戶端發(fā)一個(gè)請(qǐng)求開(kāi)始計(jì)時(shí)，到客戶端接收到從服務(wù)器端返回的響應(yīng)結(jié)果結(jié)束所經(jīng)歷的時(shí)間，響應(yīng)時(shí)間由請(qǐng)求發(fā)送時(shí)間、網(wǎng)絡(luò)傳輸時(shí)間和服務(wù)器處理時(shí)間三部分組成。VU: Virtual user，模擬真實(shí)業(yè)務(wù)邏輯步驟的虛擬用戶，虛擬用戶模擬的操作步驟都被記

4、錄在虛擬用戶腳本里。一般性能測(cè)試過(guò)程中，通俗稱之為并發(fā)用戶數(shù)。CLI/高級(jí)命令CLI/高級(jí)命令TPS波動(dòng): 系統(tǒng)性能依賴于特定的硬件、軟件代碼、應(yīng)用服務(wù)、網(wǎng)絡(luò)資源等，所以在性能場(chǎng)景執(zhí)行期間，TPS可能會(huì)表現(xiàn)為穩(wěn)定，或者波動(dòng)，抑或遵循一定的上升或下降趨勢(shì)。我們用TPS波動(dòng)系數(shù)來(lái)記錄這個(gè)指標(biāo)值。CPU: CPU資源是指性能測(cè)試場(chǎng)景運(yùn)行的這個(gè)時(shí)間段內(nèi)，應(yīng)用服務(wù)系統(tǒng)的CPU資源占用率。CPU資源是判斷系統(tǒng)處理能力以及應(yīng)用運(yùn)行是否穩(wěn)定的重要參數(shù)。Load: 系統(tǒng)正在干活的多少的度量，隊(duì)列長(zhǎng)度。系統(tǒng)平均負(fù)載，被定義為在特定時(shí)間間隔（1m，5m，15m）內(nèi)運(yùn)行隊(duì)列中的平均進(jìn)程數(shù)。I/O: I/O可分為磁盤I

5、O和網(wǎng)卡IO。JVM: 即java虛擬機(jī)，它擁有自己的處理器、堆棧、寄存器等，還有自己相應(yīng)的指令系統(tǒng)。Java應(yīng)用運(yùn)行在JVM上面。GC: GC是一種自動(dòng)內(nèi)存管理程序，它主要的職責(zé)是分配內(nèi)存、保證被引用的對(duì)象始終在內(nèi)存中、把不被應(yīng)用的對(duì)象從內(nèi)存中釋放。FGC會(huì)引起JVM掛起。網(wǎng)速: 網(wǎng)絡(luò)中的數(shù)據(jù)傳輸速率，一般以Byte/s為單位。通過(guò)ping延時(shí)來(lái)反映網(wǎng)速。流量: 性能測(cè)試中，一般指單位時(shí)間內(nèi)流經(jīng)網(wǎng)卡的總流量。分為inbound和outbound，一般以KB為單位。評(píng)估本次性能測(cè)試過(guò)程的參與人包括了阿里云應(yīng)急保障小組等多部門人員，網(wǎng)站為外部供應(yīng)商開(kāi)發(fā)，阿里云提供云 主機(jī)和技術(shù)支持。該網(wǎng)站之前前

6、期也由其他部門做了驗(yàn)收工作，進(jìn)行了完整的性能測(cè)試，報(bào)告顯示，性能較差，第一次測(cè)試，網(wǎng) 站并發(fā)數(shù)沒(méi)有超過(guò)35個(gè)，第二次測(cè)試，網(wǎng)站上做了優(yōu)化后，靜態(tài)頁(yè)面縮小后，并發(fā)用戶數(shù)100內(nèi) 5s ，200內(nèi)90%響應(yīng)在15s以上，隨著并發(fā)用戶數(shù)的增加，頁(yè)面響應(yīng)最高可到20多秒，而且訪問(wèn)明顯感覺(jué)較慢，所以聯(lián)系 了阿里云的技術(shù)支持，希望能夠幫助診斷性能問(wèn)題，給出優(yōu)化建議。測(cè)試業(yè)務(wù)并發(fā)用戶數(shù)平均響應(yīng)時(shí)間(秒)90%響應(yīng)時(shí)間（秒）首頁(yè)瀏覽10012.08215.28920023.94929.092分頁(yè)瀏覽1008.97312.34320018.84624.106經(jīng)過(guò)會(huì)議討論后，評(píng)估出最終的測(cè)試目標(biāo)：帶頁(yè)面的所有靜態(tài)

7、資源一起，響應(yīng)時(shí)間必須小于5秒，同時(shí)并發(fā)訪問(wèn) 用戶數(shù)最低500，TPS根據(jù)實(shí)際的結(jié)果來(lái)得出。性能測(cè)試目標(biāo)- 并發(fā)用戶數(shù)：=500- 業(yè)務(wù)響應(yīng)時(shí)間：5秒開(kāi)放搜索/最佳實(shí)踐開(kāi)放搜索/最佳實(shí)踐分析通過(guò)性能測(cè)試前端分析工具(未開(kāi)放)分析，頁(yè)面的響應(yīng)時(shí)間88%左右都是消耗在前端資源加載上，服務(wù)器端消 耗只占到了頁(yè)面響應(yīng)的12%左右;一個(gè)網(wǎng)站的響應(yīng)一般由四部分時(shí)間組成，前端、網(wǎng)絡(luò)、服務(wù)器和數(shù)據(jù)庫(kù)，前端主要是減小頁(yè)面大小，減小頁(yè)面 請(qǐng)求數(shù)，優(yōu)化頁(yè)面js等，網(wǎng)絡(luò)主要是使用CDN，優(yōu)化連接數(shù)等，服務(wù)器主要是優(yōu)化Apache，優(yōu)化Tomcat，優(yōu) 化java代碼等，數(shù)據(jù)庫(kù)是優(yōu)化sql語(yǔ)句，優(yōu)化索引，優(yōu)化數(shù)據(jù)存儲(chǔ)等

8、。測(cè)試和優(yōu)化頁(yè)面前端分析及優(yōu)化我們對(duì)頁(yè)面的優(yōu)化仍然從前端開(kāi)始，首先通過(guò)性能測(cè)試的前端測(cè)試工具（未開(kāi)放）進(jìn)行掃描，我們發(fā)現(xiàn)以下問(wèn) 題并優(yōu)化：Js較大，無(wú)壓縮，同時(shí)存在重復(fù)請(qǐng)求，最多一個(gè)js加載4次，已做壓縮和減少。Js位置不合理，阻礙頁(yè)面加載。外部cssBanner頁(yè)面1的后臺(tái).do有4個(gè)，減少為3個(gè)頁(yè)面2的后臺(tái)do2個(gè)，減少為1個(gè)存在加載失敗鏈接，404失敗，同時(shí)次數(shù)非常多，更換為cnzz(qq等)，且不穩(wěn)定分享功能比較慢外部資源建議異步實(shí)現(xiàn)，目前全部是jquery渲染，iframe嵌套，時(shí)間資源限制，后期優(yōu)化盡量減少或者不使用iframe頁(yè)面請(qǐng)求數(shù)太多，主要是js和css重復(fù)加載問(wèn)題和圖片較

9、小導(dǎo)致的。 經(jīng)過(guò)以上修改及配置服務(wù)器靜態(tài)資源緩存后，性能提高25%，首頁(yè)響應(yīng)從1.5秒提高到1.1秒，并且前端優(yōu)化持續(xù)進(jìn)行。服務(wù)端優(yōu)化一般核心頁(yè)面都要求在300毫秒以下，非核心頁(yè)面要求在500毫秒以下，同時(shí)重點(diǎn)關(guān)注并發(fā)時(shí)的負(fù)載和穩(wěn)定，服 務(wù)器端代碼和響應(yīng)的快速穩(wěn)定是整個(gè)頁(yè)面性能的重點(diǎn)。腳本編寫及場(chǎng)景構(gòu)造根據(jù)前期需求評(píng)估的內(nèi)容，客戶是一個(gè)門戶網(wǎng)站，主要由不同功能頁(yè)面組成的，各個(gè)功能頁(yè)面當(dāng)中又包含了靜 態(tài)內(nèi)容和異步動(dòng)態(tài)請(qǐng)求，所以，性能測(cè)試的腳本的編寫主要涵蓋了各頁(yè)面的請(qǐng)求和相關(guān)靜態(tài)資源的請(qǐng)求，這里 存在一個(gè)串行和并行的概念：串行：請(qǐng)求的頁(yè)面和頁(yè)面當(dāng)中的靜態(tài)資源、異步動(dòng)態(tài)請(qǐng)求組成一個(gè)同步請(qǐng)求，每一個(gè)

10、內(nèi)容都作為一個(gè)事務(wù)（也 可以共同組成一個(gè)事務(wù)，分開(kāi)事務(wù)的好處是可以統(tǒng)計(jì)各部分的響應(yīng)時(shí)間），這樣壓測(cè)任務(wù)執(zhí)行時(shí)，線程就會(huì)根 據(jù)事物的順序分布調(diào)用執(zhí)行，相當(dāng)于一個(gè)頁(yè)面的順序加載，弊端是無(wú)法模擬實(shí)際IE的小范圍并發(fā)，但這樣測(cè)試 的結(jié)果是最嚴(yán)格的。并行：各個(gè)頁(yè)面之前可以使用不同的任務(wù)，采用并行的混合場(chǎng)景執(zhí)行，同時(shí)設(shè)置一定的比例（并發(fā)用戶數(shù)），保證服務(wù)器承受的壓力與實(shí)際用戶訪問(wèn)相似。場(chǎng)景并發(fā)用戶數(shù)：經(jīng)常會(huì)遇到設(shè)置多大并發(fā)用戶數(shù)合適？的問(wèn)題，因?yàn)樵跊](méi)有任何思考時(shí)間的時(shí)候，我們有 一個(gè)簡(jiǎn)單的公式：VU（并發(fā)壓測(cè)用戶數(shù)） = TPS（每秒執(zhí)行事務(wù)數(shù)） RT（響應(yīng)時(shí)間）所以，在尋找合適的并發(fā)用戶數(shù)上，建議使用性

11、能測(cè)試的梯度模式，逐漸增加并發(fā)用戶數(shù)，這個(gè)時(shí)候壓力也 會(huì)越來(lái)越大，當(dāng)TPS的增長(zhǎng)率小于響應(yīng)時(shí)間的增長(zhǎng)率時(shí)，這就是性能的拐點(diǎn)，也就是最合理的并發(fā)用戶數(shù)；當(dāng)不再增長(zhǎng)或者下降時(shí)，這個(gè)時(shí)候的壓力就是最大的壓力，所使用的并發(fā)用戶數(shù)就是最大的并發(fā)用戶數(shù)。如 果此時(shí)的TPS不滿足你的要求，那么就需要尋找瓶頸來(lái)優(yōu)化。如下圖演示的一個(gè)性能曲線：負(fù)載均衡/購(gòu)買指導(dǎo)負(fù)載均衡/購(gòu)買指導(dǎo)a點(diǎn)：性能期望值b點(diǎn)：高于期望，系統(tǒng)安全c點(diǎn)：高于期望，拐點(diǎn)d點(diǎn)：超過(guò)負(fù)載，系統(tǒng)崩潰注意：使用外網(wǎng)地址壓測(cè)可能會(huì)造成瞬時(shí)流量較大，造成流量計(jì)費(fèi)，從而產(chǎn)生費(fèi)用，建議可以使用內(nèi)網(wǎng)地址壓 測(cè)，避免損失。第一階段在按照客戶提供的4個(gè)URL請(qǐng)求構(gòu)

12、造場(chǎng)景壓測(cè)以后，同時(shí)根據(jù)實(shí)際情況和客戶要求，使用性能測(cè)試，構(gòu)造相應(yīng)的 場(chǎng)景和腳本后，模擬用戶實(shí)際訪問(wèn)情況，并且腳本中加上了img、js、css等各一個(gè)的最大靜態(tài)資源：結(jié)果：靜態(tài)4000TPS，動(dòng)態(tài)1500TPS，服務(wù)器資源：CPU98%分析和優(yōu)化：服務(wù)器資源消耗較高，超過(guò)75%，存在瓶頸，分析平臺(tái)顯示：數(shù)據(jù)集成/數(shù)據(jù)入云數(shù)據(jù)集成/數(shù)據(jù)入云分析發(fā)現(xiàn)原來(lái)是apache到tomcat的連接等待導(dǎo)致，現(xiàn)象是100個(gè)并發(fā)壓測(cè)，就有100個(gè)tomcat的java線程，而且全部是runnable的狀態(tài)，輪詢很耗時(shí)間。同時(shí)發(fā)現(xiàn)用戶使用的是http協(xié)議，非ajp協(xié)議，不過(guò)這個(gè)改動(dòng)較大，需要使用mod_jk模塊，

13、時(shí)間原因， 暫緩。解決方法：性能對(duì)比：再進(jìn)行1輪壓測(cè)含動(dòng)態(tài)含靜態(tài)文件，TPS能夠從1w達(dá)到2.7W，性能提高將近3倍，并且tomcat的線程 從原來(lái)的200跑滿，降到100附近并且線程沒(méi)有持續(xù)跑滿，2.6WTPS時(shí)候CPU在80%附近發(fā)現(xiàn)機(jī)器的核數(shù)都是2核，8G內(nèi)存，對(duì)于CPU達(dá)到98%的情況，CPU是瓶頸，而對(duì)于應(yīng)用來(lái)說(shuō)比較浪 費(fèi)，所以將2核統(tǒng)一升級(jí)為4核。擴(kuò)展機(jī)器資源，從目前的4臺(tái)擴(kuò)到6臺(tái)，同時(shí)準(zhǔn)備4臺(tái)備份，以應(yīng)對(duì)訪問(wèn)量較大的情況。思考和風(fēng)險(xiǎn)：異步請(qǐng)求處理:客戶所提供的url都是html靜態(tài)，雖然頁(yè)面當(dāng)中含動(dòng)態(tài)數(shù)據(jù)，但分析后發(fā)現(xiàn)動(dòng)態(tài)數(shù)據(jù)都 是通過(guò)jquery執(zhí)行然后iframe嵌套的，所以

14、不會(huì)隨著html文件的加載而自動(dòng)加載，需要分析所有的動(dòng) 態(tài)頁(yè)面，同時(shí)壓測(cè)，這是頁(yè)面存在異步請(qǐng)求需要關(guān)注的地方。；html5不再支持。所以建議盡量不要使用或者少使用。font=Times New Roman: 腳本錄制和模擬實(shí)際用戶訪問(wèn)。當(dāng)用戶的圖片、javascript、CSS等靜態(tài)資源和后端代碼在同一臺(tái)服務(wù)器上時(shí)，需要模擬用戶的實(shí)際訪問(wèn)請(qǐng)求，壓測(cè)腳本涵蓋所有鏈接和資 源。那么使用腳本錄制功能就可以采集更全更完整的腳本。第二階段找到幾個(gè)頁(yè)面的所有動(dòng)態(tài)資源后，整合成為一個(gè)事務(wù)，串行訪問(wèn)，同時(shí)并發(fā)壓測(cè)，從而對(duì)純服務(wù)器端進(jìn)行壓測(cè)，測(cè)試結(jié)果如下圖：性能分析：頁(yè)面一和頁(yè)面二的響應(yīng)時(shí)間分別達(dá)到了5秒和2秒

15、，性能較差，整體TPS只有11性能分析：分析發(fā)現(xiàn)響應(yīng)時(shí)間高的原因主要在RDS數(shù)據(jù)庫(kù)上，數(shù)據(jù)庫(kù)此時(shí)的CPU已經(jīng)達(dá)到100%，處理較慢，懷 疑跟sql有關(guān)，分析慢sql。優(yōu)化方法：數(shù)據(jù)庫(kù)第一批優(yōu)化完畢，優(yōu)化了6條sql語(yǔ)句之前5s左右，優(yōu)化后在150ms左右，數(shù)據(jù)庫(kù)的QPS 從1k上升到6k。RDS優(yōu)化內(nèi)容包括：優(yōu)化點(diǎn)主要是調(diào)整慢sql的索引，部分sql需要調(diào)整表結(jié)構(gòu)和sql寫法，需要應(yīng)用配合才能完成優(yōu)化，優(yōu) 化前QPS在1000左右，優(yōu)化后QPS到達(dá)6000前端響應(yīng)時(shí)間從5秒降低到150毫秒，前臺(tái)TPS由150提升到1500.總的TPS可以達(dá)到2000。第三階段通過(guò)性能測(cè)試模擬用戶實(shí)際訪問(wèn)情況，

16、包括所有靜態(tài)資源，評(píng)估出當(dāng)響應(yīng)時(shí)間小于5秒的時(shí)候，最大支撐的并發(fā) 用戶數(shù)。測(cè)試結(jié)果：可以看到，所有的事務(wù)RT加起來(lái)小于5秒的情況下，并發(fā)用戶數(shù)可以達(dá)到3000(6個(gè)事務(wù)，6個(gè)腳本，每個(gè)腳本500)，遠(yuǎn)遠(yuǎn)滿足項(xiàng)目500個(gè)并發(fā)用戶的目標(biāo)?？偨Y(jié)：第四階段評(píng)估其他非主站應(yīng)用的性能以及含靜態(tài)頁(yè)面的其他5個(gè)頁(yè)面內(nèi)容，包括：搜索壓測(cè)操作壓測(cè)登錄壓測(cè)證書登入針對(duì)5個(gè)常用場(chǎng)景進(jìn)行混合壓測(cè)測(cè)試結(jié)果:發(fā)現(xiàn)的風(fēng)險(xiǎn)和問(wèn)題：測(cè)試發(fā)現(xiàn)，流量存在非常明顯的波動(dòng)，不經(jīng)過(guò)某模塊就無(wú)此問(wèn)題，發(fā)現(xiàn)有大量的reset連接，會(huì)診后總 結(jié)：端口復(fù)用導(dǎo)致的問(wèn)題。FULLNAT模式和LVS，影響到網(wǎng)站的穩(wěn)定性和性能，暫時(shí)加載該模塊，待問(wèn)題解決

17、后再加。先使用另外一個(gè)模塊代替.凌晨2點(diǎn)，針對(duì)單點(diǎn)用戶登入進(jìn)行了壓測(cè)，發(fā)現(xiàn)100并發(fā)，該業(yè)務(wù)接口已宕機(jī)，分析結(jié)果:Cache緩存 設(shè)置太小，1G內(nèi)存容量導(dǎo)致內(nèi)存溢出，已建議修改為4G。使用http協(xié)議性能不佳，早上4點(diǎn)30進(jìn)行少 量代碼優(yōu)化后，業(yè)務(wù)直接不可用，環(huán)境出現(xiàn)宕機(jī)無(wú)法修復(fù)，我們快速進(jìn)行快照恢復(fù)，5分鐘內(nèi)恢復(fù)3臺(tái) 業(yè)務(wù)機(jī)，云產(chǎn)品的優(yōu)勢(shì)盡顯。用戶log日志撐滿系統(tǒng)盤，并且一直不知這臺(tái)云主機(jī)還有數(shù)據(jù)盤，產(chǎn)品上 我們要做反思。幫助用戶已進(jìn)行掛盤及日志遷移至數(shù)據(jù)盤，減少單盤的IO壓力。壓力過(guò)大。加入inotify機(jī)制，由文件增量同步，變更為文 件系統(tǒng)的變化通知機(jī)制。將冷備及4臺(tái)備用web機(jī)器使用

18、該方式同步，目前，查看內(nèi)容分發(fā)主機(jī)IO和CPU使用率已回復(fù)正常范圍同步推送時(shí)間，根據(jù)服務(wù)器的負(fù)載，進(jìn)行調(diào)整同步時(shí)間。今天已修改為2分鐘。 由于備份量大，晚上進(jìn)行全量同步。新增4臺(tái)備用機(jī)，已關(guān)閉apache 端口 自動(dòng)從slb去除，作為冷備由于目前單點(diǎn)用戶登入入口存在架構(gòu)單點(diǎn)宕機(jī)風(fēng)險(xiǎn)，進(jìn)行登入和未登入風(fēng)險(xiǎn)驗(yàn)證，確認(rèn)，如用戶已登 入后，登入業(yè)務(wù)系統(tǒng)出現(xiàn)宕機(jī)，進(jìn)行簡(jiǎn)單的頁(yè)面點(diǎn)擊切換，不受影響容器服務(wù)/開(kāi)發(fā)者工具容器服務(wù)/開(kāi)發(fā)者工具內(nèi)存優(yōu)化按照J(rèn)VM內(nèi)存管理模式，調(diào)整系統(tǒng)啟動(dòng)參數(shù)，如果一臺(tái)ECS部署一臺(tái)服務(wù)器，建議不要選擇默認(rèn)的JVM配置，應(yīng)該設(shè)置內(nèi)存為物理內(nèi)存的一半，同時(shí)設(shè)置相應(yīng)的YTC和FGC策略

19、，觀察Old區(qū)變化，避免大量Full GC，建議Full GC頻率大于1小時(shí)，同時(shí)GC時(shí)間小于1秒鐘。架構(gòu)優(yōu)化單點(diǎn)登錄服務(wù)修改為SLBSLB內(nèi)容管理云平臺(tái)云服務(wù)器實(shí)現(xiàn)行文件差異同步，同時(shí)冷備新增4臺(tái)web機(jī)器總結(jié)備注：服務(wù)器的CPU達(dá)到100% 這其實(shí)是一個(gè)好的現(xiàn)象，說(shuō)明我們的邏輯全部已經(jīng)走到了資源消耗上，而不是由外部其他邏輯限制或blocked，這種現(xiàn)象帶來(lái)的好處就是，首先我們可以集中精力從減少代碼的資源消耗上 解決問(wèn)題，帶來(lái)性能的改善，其次，實(shí)在無(wú)法優(yōu)化我們也可以增加機(jī)器臺(tái)數(shù)，橫向擴(kuò)展來(lái)讓性能成倍的提高，這也是用成本換性能的方法。當(dāng)然，前提是架構(gòu)上支持負(fù)載均衡的分布式架構(gòu)。 總的來(lái)說(shuō)就是，

20、這種情況要不選擇從縱向優(yōu)化，或者選擇從橫向擴(kuò)展，都可以增加。遺留問(wèn)題時(shí)間原因，測(cè)試頁(yè)面有限，有些頁(yè)面沒(méi)有測(cè)試覆蓋到，比如后臺(tái)頁(yè)面。登錄系統(tǒng)存在內(nèi)存風(fēng)險(xiǎn)，由于用戶的緩存信息仍然存在單點(diǎn)問(wèn)題，所以風(fēng)險(xiǎn)較大，同時(shí)系統(tǒng)壓力不滿歸檔存儲(chǔ)/常見(jiàn)問(wèn)題歸檔存儲(chǔ)/常見(jiàn)問(wèn)題足要求，并發(fā)較高存在crash風(fēng)險(xiǎn)，未來(lái)得及發(fā)現(xiàn)瓶頸所在。徹底解決必須使用OCS等緩存系統(tǒng)改造，同時(shí)優(yōu)化數(shù)據(jù)庫(kù)。Iframe框架造成用戶體驗(yàn)不好，需要改掉，換成異步j(luò)s接口方式。后臺(tái)同步系統(tǒng)，對(duì)于資源消耗影響較大，需要持續(xù)優(yōu)化。平臺(tái)應(yīng)該提供開(kāi)發(fā)和測(cè)試進(jìn)行自主壓測(cè)、分析、評(píng)估，同時(shí)提供統(tǒng)一的測(cè)試報(bào)告，保證各部分模塊的 性能，整合起來(lái)才能保障整個(gè)門

21、戶網(wǎng)站的性能。CPU優(yōu)化還需要繼續(xù)分析跟進(jìn)，目前只是增加機(jī)器資源降低風(fēng)險(xiǎn)，成本較高。上線發(fā)布應(yīng)該具備統(tǒng)一的回歸驗(yàn)證機(jī)制，并且日常需要持續(xù)優(yōu)化，避免由于后期代碼的改動(dòng)導(dǎo)致性能 下降。訪問(wèn)性能測(cè)試控制臺(tái)訪問(wèn)性能測(cè)試控制臺(tái)大規(guī)模分布式壓測(cè)背景需要臨時(shí)擴(kuò)容他們的機(jī)器來(lái)支持100W的QPS，每秒100W的請(qǐng)求，聽(tīng)起來(lái)還是挺恐怖的。什么概念呢，2013 年雙12的大秒系統(tǒng)的峰值QPS也就在42萬(wàn)多。從這樣的數(shù)據(jù)來(lái)看，這個(gè)客戶的需求高的離譜。但是既然用戶有 這個(gè)需求，我們還是需要滿足客戶的期望。問(wèn)題及挑戰(zhàn)遇到問(wèn)題主要有：100萬(wàn)QPS被測(cè)系統(tǒng)如何搭建，需要多少臺(tái)機(jī)器選擇何種壓測(cè)工具，百萬(wàn)級(jí)QPS考驗(yàn)，壓力機(jī)

22、需要多少臺(tái)機(jī)器遇到的挑戰(zhàn)主要有：項(xiàng)目實(shí)施的時(shí)間只有5天，壓力非常大被測(cè)系統(tǒng)是否能承受如此大的壓力壓力機(jī)自身是否能經(jīng)受如此大的壓力，是否穩(wěn)定短時(shí)間內(nèi)如何快速部署被測(cè)系統(tǒng)及壓力機(jī)環(huán)境性能瓶頸在哪（程序、OS/硬件、網(wǎng)絡(luò)設(shè)備等）解決方案及評(píng)估經(jīng)過(guò)多次會(huì)議，確定解決方案是，采用阿里云環(huán)境自動(dòng)化運(yùn)維及彈性擴(kuò)容來(lái)搭建環(huán)境，壓測(cè)工具采用分布式壓測(cè)。通過(guò)評(píng)估機(jī)器數(shù)量如下：被測(cè)系統(tǒng)環(huán)境：2臺(tái)SLB,300臺(tái)ECS(4核CPU8G內(nèi)存)，批量部署應(yīng)用壓力機(jī)環(huán)境：300臺(tái)ECS（4核CPU8G內(nèi)存），批量部署性能測(cè)試整個(gè)團(tuán)隊(duì)包括客戶、SLB和ECS機(jī)器維護(hù)人員、環(huán)境部署人員以及性能測(cè)試團(tuán)隊(duì)充分密切配合。目標(biāo)QPS：

23、100萬(wàn)，穩(wěn)定運(yùn)行1分鐘左右。典型業(yè)務(wù)秒殺活動(dòng)，一個(gè)比較復(fù)雜的帶Header, Body, Cookie 的http 請(qǐng)求。測(cè)試結(jié)果結(jié)果QPS峰值最高達(dá)到71.5W，后端ECSCPU利用率最高75%，網(wǎng)絡(luò)峰值流量達(dá)到25Gb。QPS達(dá)到峰值后，逐漸下降，基本穩(wěn)定在50萬(wàn)左右。能穩(wěn)定運(yùn)行4分鐘左右。分析QPS下降的原因經(jīng)過(guò)各技術(shù)專家診斷一致認(rèn)為是SLB丟包導(dǎo)致，SLB壓力已到極限，因此建議需要配置3臺(tái)SLB，每臺(tái)SLB掛100臺(tái)ECS，才有可能滿足100萬(wàn)QPS 。結(jié)論經(jīng)過(guò)與客戶會(huì)討，峰值71.5萬(wàn)QPS，穩(wěn)定運(yùn)行4分鐘50萬(wàn)QPS，能滿足目前現(xiàn)在的業(yè)務(wù)需求。 如果需要支持OSS/計(jì)量計(jì)費(fèi)OSS

24、/計(jì)量計(jì)費(fèi)100萬(wàn)QPS，需要擴(kuò)容SLB，至少是3臺(tái)SLB以上?？偨Y(jié)分布式壓測(cè)穩(wěn)定性在測(cè)試過(guò)程中，性能測(cè)試經(jīng)受住了大規(guī)模壓力的考驗(yàn)，并且從未出現(xiàn)過(guò)異常問(wèn)題，由此可知，性能測(cè)試產(chǎn)品非 常穩(wěn)定。百萬(wàn)級(jí)QPS支持在測(cè)試的過(guò)程中，性能測(cè)試能支撐百萬(wàn)級(jí)QPS的壓力發(fā)起，這是目前其他壓測(cè)工具所不能支持的。資源消耗少雖然性能測(cè)試壓測(cè)機(jī)申請(qǐng)了300臺(tái)ECS機(jī)器，但在測(cè)試過(guò)程中，消耗的機(jī)器資源非常少，CPU利用率不到0.1%，并且每臺(tái)機(jī)器負(fù)載均衡，實(shí)際上100臺(tái)ECS就足夠了。環(huán)境搭建在調(diào)研階段，性能測(cè)試團(tuán)隊(duì)就大規(guī)模壓力發(fā)起進(jìn)行了充分的調(diào)研，并且通過(guò)測(cè)試驗(yàn)證單臺(tái)機(jī)器能發(fā)起的壓力以 及彈性擴(kuò)容，預(yù)估出需要的機(jī)器數(shù)

25、量，才能保證項(xiàng)目的順利進(jìn)行。另外阿里云批量自動(dòng)化環(huán)境搭建節(jié)省了環(huán)境的部署時(shí)間，在1天內(nèi)完成所有工作。團(tuán)隊(duì)合作這次大規(guī)模壓力壓測(cè)在5天內(nèi)順利完成，離不開(kāi)整個(gè)團(tuán)隊(duì)所有人員密切配合，重點(diǎn)關(guān)注，才能讓如此大的項(xiàng)目在 短時(shí)間內(nèi)成功實(shí)施。因此團(tuán)隊(duì)合作在項(xiàng)目實(shí)施的過(guò)程中有起著舉足輕重的作用。訪問(wèn)性能測(cè)試控制臺(tái)訪問(wèn)性能測(cè)試控制臺(tái)移動(dòng)APP項(xiàng)目實(shí)施案例分析及調(diào)優(yōu)背景隨著客戶業(yè)務(wù)發(fā)展，目前系統(tǒng)架構(gòu)已不能滿足業(yè)務(wù)發(fā)展需要，因此急需將服務(wù)器托管到阿里云上，并進(jìn)行擴(kuò)容；遷移到阿里云上以后，系統(tǒng)資源消耗是否比目前線上環(huán)境結(jié)果要好。因此在上線前需要進(jìn)行性能測(cè)試，測(cè)試 是否滿足各項(xiàng)性能指標(biāo)。測(cè)試目標(biāo)本次測(cè)試目標(biāo)如下：容量測(cè)試

26、：核心業(yè)務(wù)(核心業(yè)務(wù)1+核心業(yè)務(wù)2)+非核心業(yè)務(wù)基線（非核心業(yè)務(wù)1+非核心業(yè)務(wù)2+非核心 業(yè)務(wù)3+非核心業(yè)務(wù)4+非核心業(yè)務(wù)5+非核心業(yè)務(wù)6）混合交易容量穩(wěn)定性測(cè)試：混合交易穩(wěn)定性突變測(cè)試：非核心業(yè)務(wù)突變3倍，對(duì)核心業(yè)務(wù)的影響對(duì)比測(cè)試：和線上同等壓力下，線上和線下資源消耗和響應(yīng)時(shí)間對(duì)比?；謴?fù)性測(cè)試：模擬網(wǎng)絡(luò)攻擊架構(gòu)系統(tǒng)架構(gòu)主要有如下服務(wù)器：HTTP服務(wù)器：核心業(yè)務(wù)1和核心業(yè)務(wù)2業(yè)務(wù)TCP服務(wù)器：核心業(yè)務(wù)使用人員終端心跳業(yè)務(wù)MongoDB服務(wù)器：非結(jié)構(gòu)化數(shù)據(jù)庫(kù)存儲(chǔ)Redis服務(wù)器：信息推送MySQL服務(wù)器：結(jié)構(gòu)化數(shù)據(jù)庫(kù)存儲(chǔ)測(cè)試指標(biāo)容量測(cè)試：核心業(yè)務(wù)1TPS=600筆/秒,核心業(yè)務(wù)2TPS=1200

27、筆/秒穩(wěn)定性測(cè)試：至少在核心業(yè)務(wù)1TPS等于300筆/秒和核心業(yè)務(wù)2TPS等于600筆/秒能穩(wěn)定運(yùn)行8小時(shí)突變測(cè)試：非核心業(yè)務(wù)突變3倍，基本對(duì)核心業(yè)務(wù)無(wú)影響線上線下資源消耗對(duì)比測(cè)試：在跟線上核心業(yè)務(wù)1 TPS等于150筆/秒和核心業(yè)務(wù)2 TPS等于120筆/秒同等壓力下，測(cè)試環(huán)境的MonogoDB和RedisCPULoad小于0.5%,磁盤利用率小于0.1%線上線下存儲(chǔ)訪問(wèn)時(shí)間對(duì)比測(cè)試：在核心業(yè)務(wù)1 TPS等于200筆/秒和核心業(yè)務(wù)2 TPS等于400筆/秒的情況下，應(yīng)用觀察到的存儲(chǔ)訪問(wèn)平均耗時(shí)不超過(guò)4ms，最大耗時(shí)不超過(guò)100ms。恢復(fù)性測(cè)試：系統(tǒng)能恢復(fù)，TPS無(wú)變化消息隊(duì)列/FAQ消息隊(duì)列

28、/FAQ業(yè)務(wù)模型分析通過(guò)生產(chǎn)上高峰業(yè)務(wù)量分析得出，核心業(yè)務(wù)1和核心業(yè)務(wù)2除了雙12外，比例占比1：1.5左右，通過(guò)系統(tǒng)整個(gè)趨 勢(shì)觀察，發(fā)現(xiàn)核心業(yè)務(wù)2業(yè)務(wù)量有明顯增長(zhǎng)趨勢(shì)，因此核心業(yè)務(wù)1和核心業(yè)務(wù)2的占比為1：2。高峰時(shí)候核心業(yè) 務(wù)總的TPS只有50200筆秒。核心業(yè)務(wù)量：非核心業(yè)務(wù)量：非核心業(yè)務(wù)1+非核心業(yè)務(wù)2+非核心業(yè)務(wù)3+非核心業(yè)務(wù)4+非核心業(yè)務(wù)5+非核心業(yè)務(wù)6編號(hào)業(yè)務(wù)TPS占比1非核心業(yè)務(wù)140016.4%2非核心業(yè)務(wù)250020.5%3非核心業(yè)務(wù)383334.2%4非核心業(yè)務(wù)42108.6%5非核心業(yè)務(wù)530012.3%6非核心業(yè)務(wù)61908%合計(jì)2433100%模型模型1大數(shù)據(jù)處理服

29、務(wù)MaxCompute/圖模型大數(shù)據(jù)處理服務(wù)MaxCompute/圖模型此模型用于容量測(cè)試、穩(wěn)定性測(cè)試和恢復(fù)性測(cè)試。模型2此模型用于突變測(cè)試。模型3ACE/遷移指南ACE/遷移指南此模型用于線上線下資源消耗對(duì)比測(cè)試。模型4此模型用于線上線下存儲(chǔ)訪問(wèn)時(shí)間對(duì)比測(cè)試腳本設(shè)計(jì)經(jīng)過(guò)調(diào)研，發(fā)送后臺(tái)的業(yè)務(wù)均是URL+自定義Body方式，因此在性能測(cè)試?yán)锩?，新增一個(gè)腳本，上傳參數(shù)化文 件，定義事務(wù)，設(shè)置連接和Body就行了，注意盡可能多的進(jìn)行參數(shù)化。測(cè)試結(jié)果容量測(cè)試測(cè)試場(chǎng)景按照模型，設(shè)置用戶數(shù)比例和步調(diào)時(shí)間(保持業(yè)務(wù)占比，不偏模型)，運(yùn)行20分鐘，進(jìn)行負(fù)載測(cè)試。測(cè)試結(jié)果及分析- 第一輪測(cè)試按照核心業(yè)務(wù)1 10

30、00筆/秒和核心業(yè)務(wù)2 2000筆/秒目標(biāo)發(fā)起壓力，發(fā)現(xiàn)不能達(dá)到目標(biāo)，TPS曲線不穩(wěn)定，運(yùn)行到分鐘的時(shí)候，下降非常厲害，抖動(dòng)也非常厲害，通過(guò)監(jiān)控，發(fā)現(xiàn)FULL GC非常頻繁，達(dá)到秒次，經(jīng)過(guò)與架構(gòu)師溝通，這是由于實(shí)現(xiàn)機(jī)制導(dǎo)致的，核心業(yè)務(wù)1的機(jī)制是將內(nèi)容放到隊(duì)列里 面，隊(duì)列長(zhǎng)度是2147483647,后臺(tái)只有64個(gè)線程（不能修改）在消化，消費(fèi)者（消化）處理速度的比 生產(chǎn)者（核心業(yè)務(wù)1）慢，導(dǎo)致隊(duì)列長(zhǎng)度越來(lái)越大，內(nèi)存很快被消化完了，導(dǎo)致FULL GC頻繁，這屬于架構(gòu)問(wèn)題，不能進(jìn)行修改。核心業(yè)務(wù)2：第二輪測(cè)試按照核心業(yè)務(wù)1 600筆/秒和核心業(yè)務(wù)2 1200筆/秒發(fā)起壓力，運(yùn)行20分鐘，TPS基本保持

31、穩(wěn)定，通過(guò)監(jiān)控發(fā)現(xiàn)，order應(yīng)用連接MongoDB連接數(shù)報(bào)已滿的異常錯(cuò)誤、logserver IO過(guò)高、MongoDB locked DB值高于75%。 按照核心業(yè)務(wù)1 800筆/秒和核心業(yè)務(wù)2 1600筆/秒目標(biāo)發(fā)起壓力，不能達(dá)到此目標(biāo)，TPS曲線非常不穩(wěn)定。第三輪測(cè)試mongoDB 只有表鎖沒(méi)有行鎖，導(dǎo)致locked值非常高，這個(gè)是產(chǎn)品問(wèn)題，沒(méi)辦法進(jìn)行調(diào)優(yōu)。將order應(yīng)用MongoDB連接數(shù)從250調(diào)到1000;logserver 磁盤換成效率更高SSD磁盤；重新按照核心業(yè)務(wù)1 800筆/秒和核心業(yè)務(wù)2 1600筆/秒目標(biāo)發(fā)起壓力，運(yùn)行20分鐘，TPS曲線基本穩(wěn)定。核心業(yè)務(wù)1：核心業(yè)務(wù)

32、2：測(cè)試結(jié)論系統(tǒng)的容量為核心業(yè)務(wù)1 800筆/秒和核心業(yè)務(wù)2 1600筆/秒，滿足核心業(yè)務(wù)1 600筆/秒和核心業(yè)務(wù)2 1200筆/秒目標(biāo)要求。線上線下資源消耗對(duì)比測(cè)試阿里云大數(shù)據(jù)平臺(tái)/移動(dòng)定向營(yíng)銷阿里云大數(shù)據(jù)平臺(tái)/移動(dòng)定向營(yíng)銷測(cè)試場(chǎng)景按照模型3發(fā)起壓力，在核心業(yè)務(wù)1 150TPS和核心業(yè)務(wù)2 120TPS壓力情況下，運(yùn)行20分鐘，資源消耗對(duì)比。測(cè)試結(jié)果及分析MongoDBRedis CPU Load均小于0.5CPU10%,磁盤利用率均小于0.1%,測(cè)試結(jié)論在跟線上同等壓力的情況下，阿里云環(huán)境各項(xiàng)指標(biāo)結(jié)果略好于目前線上環(huán)境資源消耗。線上線下存儲(chǔ)訪問(wèn)時(shí)間對(duì)比測(cè)試測(cè)試場(chǎng)景按照模型發(fā)起壓力，在核心業(yè)務(wù)1 200筆/秒和核心業(yè)務(wù)2 400筆/秒的壓力下，運(yùn)行20分鐘，觀察存儲(chǔ)訪問(wèn)的時(shí)間。測(cè)試結(jié)果及分析在xflush上面觀察到的存儲(chǔ)耗時(shí)值小于3ms，最大值不超過(guò)100ms測(cè)試結(jié)論滿足目標(biāo)平均耗時(shí)不超過(guò)4ms，最大耗時(shí)不超過(guò)100ms的需求。突變測(cè)試測(cè)試場(chǎng)景按照模型，在核心業(yè)務(wù)1 TPS 400筆/秒和核心業(yè)務(wù)2 TPS 800筆/秒的情況下，平穩(wěn)運(yùn)行分鐘后，將非核心業(yè)務(wù)按照基線的倍進(jìn)行突變，運(yùn)行分