說到性能測試，我們到底是想談論什么？
任何做產品的，都希望自己家的產品，品質優，性能好，服務海量用戶，還不出問題。
任何使用產品的，都喜歡自己購買的產品功能全，性能優，不花一分冤枉錢。
不過理想很豐滿，現實很骨感。實際產品的性能與開發周期，部署方式，軟硬件性能等都息息相關。所以真正提到做性能測試的場景，多數是為滿足特定需求而進行的度量或調優。
比如：
- 針對交付客戶的軟硬件環境，提供性能測試報告，證明對客戶需求的滿足
- 針對特定的性能瓶頸，進行針對性測試，為問題定位提供幫助
- 重大功能迭代，架構設計上線前的性能評估
所有的這些場景，都隱含着對性能測試目標的確認，這一點非常重要。因為如果沒有明確的測試目標，為了做而做，多數情況是沒有價值的，浪費精力。
而性能測試的目標一般是期望支持的目標用戶數量，負載，QPS等等，這些信息一般可以從業務負責人或者產品經理處獲得。當然如果有實際的業務數據支持，也可以據此分析得出。所以在開展性能測試之前，一定要先搞清楚測試目標。
目標明確之后，如何開展性能測試？
有了性能測試目標，之后還需要進一步拆解，做到具體可執行。根據經驗，個人認為性能測試的執行，最終會落地到以下兩個場景：
- 在特定硬件條件，特定部署架構下，測試系統的最大性能表現
- 在相同場景，相同硬件配置下，與競品比較，與過往分析，總結出優劣
不同的目的，做事的方式也不一樣。
第一類場景，因為結果的不確定性，測試時需要不斷的探索測試矩陣，找出盡可能優的結果。
第二類場景，首先需要理清楚，業界同類產品，到底比的是什么，相應的測試工具是什么，測試方法是什么。總之要在公平公正的條件下，遵循業界標准，得出測試結果，給出結論。
所有的性能測試場景，都需要有明確的分析與結論，以支持上述兩個場景下的目的達成。測試場景要貼近實際的目標場景，測試數據要貼近實際的業務數據，最好就用目標業務場景下的數據來進行性能測試。
服務端性能測試到底要看哪些指標?
不同的領域，業務形態，可能關注的性能指標是不一樣的，所以為了表述精確，我們這里只談服務端的性能測試指標。
一般我們會用以下指標來衡量被測業務: QPS, 響應時間(Latency), 成功率，吞吐率，以及服務端的資源利用率(CPU/Memory/IOPS/句柄等)。
不過，這里有一些常識需要明確:
- 響應時間不要用平均值，要用百分值。比如常見的，98值(98th percentile)表示。
- 成功率是性能數據采集標准的前提，在成功率不足的情況下，其他的性能數據是沒意義的(當然這時候可以基於失敗請求來分析性能瓶頸)。
- 單獨說QPS不夠精確，而應結合響應時間綜合來看。比如 "在響應時間TP98都小於100ms情況下，系統可以達到10000qps" 這才有意義。
- 性能測試一定要持續一定時間，在確保被測業務穩定的情況下，測出的數據才有意義。
要多體會下這些常識，實戰中很多新手對這塊理解不深，導致有時出的性能數據基本是無效的。
為什么性能測試報告一定要給出明確的軟硬件配置，以及部署方式？
前面說到，性能數據是與軟件版本，硬件配置，部署方式等息息相關的。每一項指標的不同，得出的數據可能是天差萬別。所以在做性能測試時，一定要明確這些基礎前置條件，且在后期的性能測試報告中，清晰的說明。
jmeter, ab, wrk, lotust, k6 這么多性能測試工具，我應該選擇哪個？
業界性能測試數據工具非常多，不過適用的場景，以及各自特點會有不同。所以針對不同的性能測試需求，應當選擇合適的性能工具。比如:
- jmeter: 主要提供圖形化操作以及錄制功能，入門簡單，功能也較強大。缺點是需要額外安裝。
- ab(apech benchmark): 簡單好用，且一般系統內置了，應對簡單場景已足夠
- lotust：簡單好用，支持python編寫自定義腳本，支持多worker，圖形化界面匯總性能數據。
這里不一一介紹工具，大家有興趣的都可以自行去網上搜索。
其實筆者在實踐過程中發現，其實絕大多數性能測試場景，都需要編碼實現。所以如何優雅的結合現有的測試代碼，環境，以及基礎設施，來方便的進行性能測試反而是個可以考量的點。
筆者比較認可Go+Prometheus+Kubernetes的模式。首先go語言因其獨有的並發模式，上手簡單等特點，在雲服務，服務端程序領域使用已經非常廣了，采用其寫腳本，也許與被測程序天然緊密結合。且服務端程序要想很好的運維，必然有一套完整的監控告警體系，而Prometheus基本是其中熱度最高的，使用范圍最廣的，同時我們也可以將測試程序性能數據打點到Prometheus，這樣在計算QPS，成功率等指標上，非常方便。
另外大家知道，在性能測試時，多數需要不斷的調整metrix，比如並發數，worker數量等，來探測系統的性能表現，這時候如果將測試程序跑在Kubernetes上，就可以借助其能力，比如Deployment，靈活的部署和水平擴展，體驗相當優雅。
單機10000並發為什么可能不靠譜？
我們知道使用goroutine，可以瞬間開很多並發，非常好用。於是可能就會有同學覺得用它做性能測試很方便，直接寫個腳本，起超多的並發，去做性能測試。但這樣真的靠譜嗎？
雖然go語言的並發，通過P，G，M模型，在調度goroutine時，比較高效，但無論如何，任何的程序執行，最終消耗的都是系統資源，測試腳本也同樣。所以單機上執行的並發效果，最終會受限於，你腳本的復雜程序，也就是對CPU,IO，網絡等系統資源的消耗。所以，並不是並發越多越好，一定是基於實際環境，通過不斷調節並發數量，worker數量等，來達到最佳姿勢。
構建業務性能數據的持續可觀測性對產品質量意義重大
一次專項性的性能分析，可以觀察當前業務的性能表現，進一步的分析性能瓶頸，為之后的改進提供幫助，意義挺大。但只這樣可能不夠全面，因為指不定的某次迭代，句柄沒關，goutinue泄露，就會造成性能問題，如果我們沒有常態化的檢測手段，等上線后才發現，很明顯不是我們想看到的。
所以更優雅的做法是，將性能測試常態化的持續運營，甚至可以做到每次PR觸發，都自動執行性能測試，檢測性能問題。
To-Be-Continued
性能測試對保障產品質量，提升用戶體驗意義重大。筆者這里只羅列了一些個人在實際工作中看的問題，以及一些體會，可能不全面。所以如果您有問題，歡迎拋出來，共同探討。
參考資料
- https://coolshell.cn/articles/17381.html
- https://www.dynatrace.com/news/blog/why-averages-suck-and-percentiles-are-great/
- https://automationrhapsody.com/how-to-do-proper-performance-testing/
Contact me ?
Email: jinsdu@outlook.com
Blog: http://www.cnblogs.com/jinsdu/
Github: https://github.com/CarlJi