性能測試必知必會

說到性能測試，咱們究竟是想談論什麼？

任何作產品的，都但願本身家的產品，品質優，性能好，服務海量用戶，還不出問題。

任何使用產品的，都喜歡本身購買的產品功能全，性能優，不花一分冤枉錢。

不過理想很豐滿，現實很骨感。實際產品的性能與開發週期，部署方式，軟硬件性能等都息息相關。因此真正提到作性能測試的場景，多數是爲知足特定需求而進行的度量或調優。

好比：

• 針對交付客戶的軟硬件環境，提供性能測試報告，證實對客戶需求的知足
• 針對特定的性能瓶頸，進行鍼對性測試，爲問題定位提供幫助
• 重大功能迭代，架構設計上線前的性能評估

全部的這些場景，都隱含着對性能測試目標的確認，這一點很是重要。由於若是沒有明確的測試目標，爲了作而作，多數狀況是沒有價值的，浪費精力。

而性能測試的目標通常是指望支持的目標用戶數量，負載，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