周一項目經理給我提了一個性能測試需求：對庫存查詢功能遷移后的服務器處理能力做一次壓力測試，下班到家給測試群的小伙伴說起這事，引起了一些討論。。。
紫川（我建的測試交流群的某個咸魚）吐槽我寫性能測試博客一直不寫實際操作方法，我的回答是：最好的學習方法是跟着學、照着做，思考咨詢總結實踐。。。
只是截圖表示操作過程，是沒多大參考意義的，思考分析的方法和思維更重要（這種思考分析的方法需要練習和知識的積累）。。。
習慣將自己成長的收獲進行記錄，這篇博客就記錄下自己在這次壓測過程中的分析方法和操作過程。。。
1、性能測試需求
| 響應時間 | ≤20S |
| 網絡環境 | 公司100M內網 |
| 壓測環境 | 生產環境壓測：模擬綜合業務場景 |
| 業務場景 | 庫存查詢功能由后台遷移至移動端：后台有800個查詢入口，移動端變為6400個入口 |
| 服務器配置 | 雲服務器 |
2、需求分析
需求如上，性能測試最關注的三個指標分別是：響應時間、TPS、資源使用情況。
根據需求來看，要求響應時間不能超過20S的前提下，通過壓力測試得到服務器的最大處理能力；且只是一個庫存查詢功能，因為是在線上壓測，所以業務場景可以保證是真實可靠的。
3、場景建模
壓測環境是生產環境，所以交叉的業務場景較復雜，庫存查詢功能是針對雲服務器，其他的部分業務是通過應用服務器到數據庫的，且數據庫做了讀寫分離，故暫不考慮數據庫的性能問題。
4、測試數據准備
測試數據的來源一般有這幾種方式：
①、將生產的數據完全備份過來：優點是完全真實可靠，不足之處在於測試數據在測試中容易造成數據污染，最好進行數據隔離，以盡量保證數據的可用性。
②、通過模擬業務場景跑腳本或者調度任務來產生數據：在測試數據量不大的情況下可以通過這種方式來准備測試數據。
這里的前提是在測試環境進行壓力測試，而本次的壓測是直接在生產環境，故測試數據的問題已經算是解決了。
5、腳本開發&調試
測試工具是jmeter，因為只針對查詢庫存的功能，故只需要進行單接口壓測即可。
利用測試工具設計測試腳本的好處是省卻了很多繁瑣的過程，腳本的調試，首先需要進行接口測試，保證測試的接口是正確可用，然后進行單接口基准測試，最后進行壓力測試。
6、腳本執行&記錄監控
腳本執行：
在腳本執行過程中，需要由小到大逐漸加大並發數，且記錄每次的測試結果，由於網絡等情況影響，最好的辦法是同一並發數執行多次測試，然后加權平均到的的數值相對來說較可靠。
通過記錄不斷加壓測試后的測試數據，可以觀察到響應時間、TPS、資源使用情況等數值的變化，然后進行分析。
記錄監控：
每次測試執行的結果進行記錄，監控數據庫響應時間、連接數，服務器內存、磁盤使用等數值。
PS：由於是在生產環境直接壓測，故需要實時監控，以免壓測造成服務宕機等嚴重情況（我執行測試時候開發隨時待命，准備重啟服務和擴容233）。
性能測試最重要的三個數值：響應時間、TPS、內存、磁盤使用率————監控（jmeter插件、serveragent）
關於jmeter插件：serveragent的使用，后續的博客會進行介紹。
7、結果分析&瓶頸定位
通過上面測試得到的測試數據，可以進行針對性的分析，比如在壓測過程中，資源、內存、連接數等是否使用飽和，是否有線程等待，數據庫響應時間等，然后利用排除法和優先級進行調優。
排除法：針對可能影響到性能的幾個因素，一個個分析排除；
優先級：根據實際情況，對調優的投入和時間等需要花費的時間和資源進行評估，排優先級，選擇最合適的方案。
8、調優&驗證
關於調優，我本人技術比較薄弱，就不獻丑了，說說我自己知道的一些調優方法：
內存、磁盤：簡單粗暴的做法，直接加服務器吧。。。
數據庫：更改配置的連接數，加索引、讀寫分離、分庫、分區、分表、物理視圖等手段。。。
連接池：優化連接池配置，增加連接數等，具體請看鏈接博客的介紹。。。
前端：減少請求連接，數據包盡量放在body中，圖片壓縮、異步加載、JavaScript腳本放在HTML最后等等手段，具體請看鏈接博客的介紹。。。
末尾：性能測試水太深，我們公司的性能測試，只能說小打小鬧，真正的性能測試，也就大公司做得起（性能測試投入成本很大），大公司有這個需求（小公司哪來的線上流量。。。）。
推薦大家幾篇博客，了解下阿里的全鏈路壓測、餓了么全鏈路壓測。