一次簡單的壓力測試實例

週一項目經理給我提了一個性能測試需求：對庫存查詢功能遷移後的服務器處理能力作一次壓力測試，下班到家給測試羣的小夥伴提及這事，引發了一些討論。。。

紫川（我建的測試交流羣的某個鹹魚）吐槽我寫性能測試博客一直不寫實際操做方法，個人回答是：最好的學習方法是跟着學、照着作，思考諮詢總結實踐。。。

只是截圖表示操做過程，是沒多大參考意義的，思考分析的方法和思惟更重要（這種思考分析的方法須要練習和知識的積累）。。。

習慣將本身成長的收穫進行記錄，這篇博客就記錄下本身在此次壓測過程當中的分析方法和操做過程。。。

 

一、性能測試需求

響應時間	≤20S
網絡環境	公司100M內網
壓測環境	生產環境壓測：模擬綜合業務場景
業務場景	庫存查詢功能由後臺遷移至移動端：後臺有800個查詢入口，移動端變爲6400個入口
服務器配置	雲服務器

 

二、需求分析

需求如上，性能測試最關注的三個指標分別是：響應時間、TPS、資源使用狀況。

根據需求來看，要求響應時間不能超過20S的前提下，經過壓力測試獲得服務器的最大處理能力；且只是一個庫存查詢功能，由於是在線上壓測，因此業務場景能夠保證是真實可靠的。

 

三、場景建模

壓測環境是生產環境，因此交叉的業務場景較複雜，庫存查詢功能是針對雲服務器，其餘的部分業務是經過應用服務器到數據庫的，且數據庫作了讀寫分離，故暫不考慮數據庫的性能問題。

 

四、測試數據準備

測試數據的來源通常有這幾種方式：

①、將生產的數據徹底備份過來：優勢是徹底真實可靠，不足之處在於測試數據在測試中容易形成數據污染，最好進行數據隔離，以儘可能保證數據的可用性。

②、經過模擬業務場景跑腳本或者調度任務來產生數據：在測試數據量不大的狀況下能夠經過這種方式來準備測試數據。

這裏的前提是在測試環境進行壓力測試，而本次的壓測是直接在生產環境，故測試數據的問題已經算是解決了。

 

五、腳本開發&調試

測試工具是jmeter，由於只針對查詢庫存的功能，故只須要進行單接口壓測便可。

利用測試工具設計測試腳本的好處是省卻了不少繁瑣的過程，腳本的調試，首先須要進行接口測試，保證測試的接口是正確可用，而後進行單接口基準測試，最後進行壓力測試。

 

六、腳本執行&記錄監控

腳本執行：

在腳本執行過程當中，須要由小到大逐漸加大併發數，且記錄每次的測試結果，因爲網絡等狀況影響，最好的辦法是同一併發數執行屢次測試，而後加權平均到的的數值相對來講較可靠。

經過記錄不斷加壓測試後的測試數據，能夠觀察到響應時間、TPS、資源使用狀況等數值的變化，而後進行分析。

記錄監控：

每次測試執行的結果進行記錄，監控數據庫響應時間、鏈接數，服務器內存、磁盤使用等數值。

PS：因爲是在生產環境直接壓測，故須要實時監控，以避免壓測形成服務宕機等嚴重狀況（我執行測試時候開發隨時待命，準備重啓服務和擴容233）。

性能測試最重要的三個數值：響應時間、TPS、內存、磁盤使用率————監控（jmeter插件、serveragent）

關於jmeter插件：serveragent的使用，後續的博客會進行介紹。

 

七、結果分析&瓶頸定位

經過上面測試獲得的測試數據，能夠進行鍼對性的分析，好比在壓測過程當中，資源、內存、鏈接數等是否使用飽和，是否有線程等待，數據庫響應時間等，而後利用排除法和優先級進行調優。

排除法：針對可能影響到性能的幾個因素，一個個分析排除；

優先級：根據實際狀況，對調優的投入和時間等須要花費的時間和資源進行評估，排優先級，選擇最合適的方案。

 

八、調優&驗證

關於調優，我本人技術比較薄弱，就不獻醜了，說說我本身知道的一些調優方法：

內存、磁盤：簡單粗暴的作法，直接加服務器吧。。。

數據庫：更改配置的鏈接數，加索引、讀寫分離、分庫、分區、分表、物理視圖等手段。。。

鏈接池：優化鏈接池配置，增長鏈接數等，具體請看連接博客的介紹。。。

前端：減小請求鏈接，數據包儘可能放在body中，圖片壓縮、異步加載、JavaScript腳本放在HTML最後等等手段，具體請看連接博客的介紹。。。

 

末尾：性能測試水太深，咱們公司的性能測試，只能說小打小鬧，真正的性能測試，也就大公司作得起（性能測試投入成本很大），大公司有這個需求（小公司哪來的線上流量。。。）。

推薦你們幾篇博客，瞭解下阿里的全鏈路壓測、餓了麼全鏈路壓測。