壓測結果老是達不到預期,首先要大體判斷性能可能出現的瓶頸點,再有針對性的具體分析,這種狀況下能夠從如下幾個方面來排查:數據庫
一、壓測策略設置是否合理,正常狀況下,壓測過程分爲起壓、加壓、穩定施壓幾個階段,起壓不能設置的太高,加壓不能遞增得過快;緩存
二、帶寬是否足夠用,可根據一次報文請求、響應大小 * QPS * 8 與帶寬大小進行比較判斷帶寬是否夠用;性能優化
三、接口請求的報文、報文頭參數、響應結果報文等是否過大,過大的報文會影響用戶請求時間和響應時間,致使系統併發處理能力降低;服務器
四、同一個頁面(特別是首頁、活動承接頁的)請求接口是否過多,通常建議同一個頁面的接口不要超過3個;架構
五、SLB/NGINX參數設置是否合理,如鏈接數大小、空閒關閉時間等參數;併發
六、HTTP線程池參數設置是否合理;負載均衡
七、數據庫是否存在慢SQL,通常耗時超過0.5s的都認爲是潛在的慢SQL,超過1s的都認爲是慢SQL,建議在測試環境(非線上環境)作一遍全面的慢SQL排雷壓測,PR鏈路涉及到的全部關鍵表,壓測前建議單表數據量在800W以上進行壓測,數據量太少不容易發現慢SQL;性能
八、數據庫方面優化:經過SQL邏輯優化、索引優化、歷史數據定時備份(單表數據量建議不要超過500W)、讀寫分離、分庫分表等提高數據庫查詢能力;測試
九、緩存更新策略是否正常,若有些系統設置每5分鐘緩存和數據庫進行一次更新同步,此時性能出現明顯降低,這種狀況下明顯更新策略有問題,緩存更新策略須要重點關注是否可能存在雪崩、穿透的的狀況;優化
十、代碼優化,如線程阻塞問題等;
十一、架構方面的優化,如沒有緩存的能夠經過增長緩存來下降數據庫壓力從而提高系統性能、或者單臺服務器的能夠考慮負載均衡等等;