1. 系統(tǒng)性能評(píng)估的核心指標(biāo)解析當(dāng)我們需要評(píng)估一個(gè)在線系統(tǒng)的處理能力時(shí)TPSTransactions Per Second和并發(fā)數(shù)是最關(guān)鍵的兩個(gè)性能指標(biāo)。作為在電商平臺(tái)經(jīng)歷過多次大促壓測(cè)的老兵我深知這兩個(gè)數(shù)字背后代表的意義遠(yuǎn)比表面看起來復(fù)雜得多。TPS衡量的是系統(tǒng)每秒鐘能夠成功處理的業(yè)務(wù)事務(wù)數(shù)量。比如一個(gè)下單接口的TPS是500意味著這個(gè)接口每秒可以處理500筆訂單請(qǐng)求。而并發(fā)數(shù)則是指系統(tǒng)同時(shí)處理的請(qǐng)求數(shù)量它反映了系統(tǒng)的并行處理能力。這兩個(gè)指標(biāo)看似簡(jiǎn)單但在實(shí)際評(píng)估過程中需要考慮的因素非常多包括網(wǎng)絡(luò)延遲、數(shù)據(jù)庫(kù)性能、緩存命中率、線程池配置等等。2. TPS的詳細(xì)計(jì)算方法與影響因素2.1 TPS的基礎(chǔ)計(jì)算公式TPS的理論計(jì)算公式很簡(jiǎn)單TPS 并發(fā)數(shù) / 平均響應(yīng)時(shí)間(秒)舉個(gè)例子如果系統(tǒng)并發(fā)數(shù)是100平均響應(yīng)時(shí)間是200毫秒0.2秒那么理論TPS就是100/0.2500。但實(shí)際生產(chǎn)環(huán)境中這個(gè)數(shù)字會(huì)受到各種因素的影響。2.2 影響TPS的關(guān)鍵因素?cái)?shù)據(jù)庫(kù)性能我經(jīng)歷過一個(gè)案例當(dāng)數(shù)據(jù)庫(kù)連接數(shù)達(dá)到100時(shí)TPS就開始急劇下降。后來發(fā)現(xiàn)是數(shù)據(jù)庫(kù)連接池配置不當(dāng)導(dǎo)致的。緩存命中率在內(nèi)容分發(fā)系統(tǒng)中當(dāng)緩存命中率從95%降到85%時(shí)TPS可能會(huì)下降30%以上。網(wǎng)絡(luò)帶寬特別是在處理大文件上傳下載時(shí)網(wǎng)絡(luò)帶寬往往成為瓶頸。代碼質(zhì)量我曾經(jīng)優(yōu)化過一個(gè)循環(huán)中的字符串拼接操作就使TPS提升了15%。重要提示TPS測(cè)試一定要在系統(tǒng)資源CPU、內(nèi)存、IO使用率不超過70%的情況下進(jìn)行否則測(cè)試結(jié)果會(huì)失真。3. 并發(fā)數(shù)的正確理解與評(píng)估方法3.1 并發(fā)數(shù)的三種常見理解用戶并發(fā)數(shù)同時(shí)在線用戶數(shù)請(qǐng)求并發(fā)數(shù)同時(shí)處理的HTTP請(qǐng)求數(shù)線程并發(fā)數(shù)應(yīng)用服務(wù)器的工作線程數(shù)這三者經(jīng)常被混淆但實(shí)際含義和影響完全不同。我曾經(jīng)遇到過一個(gè)項(xiàng)目客戶說需要支持1萬并發(fā)結(jié)果發(fā)現(xiàn)他們指的是在線用戶數(shù)實(shí)際需要的請(qǐng)求并發(fā)數(shù)只有200左右。3.2 并發(fā)數(shù)的合理評(píng)估方法峰值預(yù)估法預(yù)估并發(fā)數(shù) 日均PV × 峰值系數(shù) / 86400 × 平均停留時(shí)間其中峰值系數(shù)通常在2-10之間視業(yè)務(wù)特點(diǎn)而定。二八法則 80%的請(qǐng)求通常集中在20%的時(shí)間段內(nèi)可以用這個(gè)規(guī)律來估算并發(fā)量。實(shí)際測(cè)量法 使用JMeter等工具模擬真實(shí)用戶行為進(jìn)行測(cè)試。4. 性能測(cè)試的實(shí)戰(zhàn)經(jīng)驗(yàn)分享4.1 測(cè)試環(huán)境搭建要點(diǎn)測(cè)試機(jī)配置一定要確保測(cè)試機(jī)的性能足夠我曾經(jīng)因?yàn)闇y(cè)試機(jī)CPU不足而誤判系統(tǒng)性能瓶頸。網(wǎng)絡(luò)環(huán)境最好使用和生產(chǎn)環(huán)境相同的網(wǎng)絡(luò)配置包括帶寬、延遲等。數(shù)據(jù)準(zhǔn)備測(cè)試數(shù)據(jù)量至少要達(dá)到生產(chǎn)環(huán)境的20%否則測(cè)試結(jié)果可能不準(zhǔn)確。4.2 測(cè)試腳本編寫技巧思考時(shí)間(Think Time)設(shè)置要模擬真實(shí)用戶操作間隔通常設(shè)置在3-10秒。參數(shù)化處理特別是對(duì)于需要登錄的系統(tǒng)一定要做好用戶數(shù)據(jù)的參數(shù)化。斷言設(shè)置不僅要檢查HTTP狀態(tài)碼還要驗(yàn)證返回?cái)?shù)據(jù)的正確性。4.3 常見測(cè)試誤區(qū)只測(cè)試接口不測(cè)試前端實(shí)際上前端性能對(duì)用戶體驗(yàn)影響很大。忽略環(huán)境差異測(cè)試環(huán)境和生產(chǎn)環(huán)境的配置差異可能導(dǎo)致測(cè)試結(jié)果失真。不做階梯式加壓直接上最大并發(fā)數(shù)可能會(huì)導(dǎo)致系統(tǒng)瞬間崩潰無法獲取準(zhǔn)確的性能曲線。5. 性能優(yōu)化實(shí)戰(zhàn)案例5.1 數(shù)據(jù)庫(kù)優(yōu)化案例在一次電商大促準(zhǔn)備中我們發(fā)現(xiàn)訂單查詢接口的TPS只有150遠(yuǎn)低于預(yù)期。通過分析發(fā)現(xiàn)缺少關(guān)鍵索引導(dǎo)致查詢效率低下事務(wù)隔離級(jí)別設(shè)置過高連接池配置不合理優(yōu)化后TPS提升到了600效果顯著。5.2 緩存優(yōu)化案例一個(gè)內(nèi)容管理系統(tǒng)在高峰期響應(yīng)變慢分析發(fā)現(xiàn)緩存鍵設(shè)計(jì)不合理導(dǎo)致命中率低緩存雪崩問題嚴(yán)重本地緩存和分布式緩存使用不當(dāng)通過引入多級(jí)緩存架構(gòu)和合理的過期策略系統(tǒng)性能提升了40%。5.3 代碼優(yōu)化案例曾經(jīng)處理過一個(gè)批量導(dǎo)入接口的性能問題發(fā)現(xiàn)存在N1查詢問題大量使用反射導(dǎo)致性能損耗日志打印過于頻繁通過重構(gòu)代碼TPS從50提升到了300。6. 性能監(jiān)控與持續(xù)優(yōu)化6.1 關(guān)鍵監(jiān)控指標(biāo)系統(tǒng)層面CPU使用率、內(nèi)存使用率、磁盤IO、網(wǎng)絡(luò)帶寬應(yīng)用層面JVM內(nèi)存、線程狀態(tài)、GC情況業(yè)務(wù)層面關(guān)鍵接口響應(yīng)時(shí)間、錯(cuò)誤率、超時(shí)率6.2 監(jiān)控工具推薦系統(tǒng)監(jiān)控Prometheus Grafana應(yīng)用監(jiān)控SkyWalking、Arthas日志分析ELK Stack6.3 性能優(yōu)化閉環(huán)流程監(jiān)控發(fā)現(xiàn)問題分析定位瓶頸實(shí)施優(yōu)化方案驗(yàn)證優(yōu)化效果總結(jié)經(jīng)驗(yàn)沉淀在實(shí)際工作中性能優(yōu)化是一個(gè)持續(xù)的過程。我建議至少每季度做一次全面的性能評(píng)估在重大業(yè)務(wù)活動(dòng)前一定要進(jìn)行壓力測(cè)試。記住沒有最好的性能數(shù)字只有最適合業(yè)務(wù)需求的性能指標(biāo)。關(guān)鍵是要建立完善的監(jiān)控體系做到有問題早發(fā)現(xiàn)、早解決。