性能測試從入門到入土的一點思考

我爲何要寫這篇文章

性能測試是軟件產品在發佈以前必須通過的一個步驟，或在POC之時，或在UAT以前。而不一樣公司的業務系統千千萬，本文將闡述性能測試會被忽略的地方，以及做者在實際性能測試工做期間遇到的問題。但願能對您有一點小小的啓發或者幫助。

性能測試工具

我經常使用的性能測試工具爲：

• Apache Benchmark（AB）
• Apache JMeter
• HP LoadRunner（LR）（收費）

AB我的認爲更適合對純粹的api接口進行經過率測試，或者僅僅是爲了獲取TPS，簡單高效。LR的性能最佳，圖表展現好，沒有缺點，缺點就是收費（貴不是LR的缺點，是個人缺點）。因爲JMeter是開源的，且插件豐富，併發性能恰好知足系統需求，我最終選擇了它。

如何確立壓測方案

萬事開頭難，性能測試最難的地方就是如何制定切實有效的測試方案。不一樣於以往的功能測試，更偏向對於業務的理解。而性能測試，每每想模擬出最真實的實際生產狀況下系統會呈現出什麼樣的問題。

我的以下建議：

1. 與系統架構師取的良好溝通，獲取總體的系統架構，確立壓測的起點（每每通常是從網關開始，但不一樣的系統又可能有多個業務網關或者對接第三方系統網關）。

2.從業務架構師那獲取性能測試的重點，在大數據、微服務大背景下，業務系統每每會被拆分紅多個子服務。有的時候爲了針對性體現報告數據，有可能會對某些子服務作針對性性能測試（性能不夠，數據來湊~）。避免浪費過多精力。

3.及時分析數據，造成報告。

性能測試坑點（乾貨）

我曾遇到如下坑點（或者說犯的錯）：

1. 壓力測試前並未作基準測試（後來在技術老大的指導下才知道，壓力測試必須作基準測試，並且要仿真業務系統實際狀況去作基準測試）。
2. 從技術層面上說，壓力測試的目標，充分使用硬件資源，把服務器的每一個核，能有90%的使用率，說明CPU的性能都使用了（而這點對於開發人員來講，是相反的。就像咱們在使用本身的電腦時，cpu佔用越低咱們越開心，而服務器上理想最佳使用效果就是99%的使用率）。
3. 針對特色業務場景，分清是「計算密集型」仍是「I/O密集型」。
4. 日誌打印真的很耗時，建議異步寫。
5. 我的認爲nmon的圖表真的不錯。
6. 用於壓力測試的線程數不宜過多，避免因CPU頻繁切換形成額外的性能損耗。

歡迎關注個人公號：彪悍大藍貓，持續分享大數據、SpringCloud乾貨~