前提：性能壓測中我們需要明白以下幾點
1、好的開始是成功的一半，前期的準備非常重要
2、過程中，關注每個細節，多個維度監控
3、在調優中多積累經驗
4、對結果負責，測試報告要清晰易懂，追求數據的準確性
一、如何分析性能數據（測試結果）
答：主要從吞吐量，錯誤率，資源監控數據，比如一個接口的處理能力爲100個/s，高於需求的期望值。錯誤率爲0.001%，期望值爲0.01%,最高cpu佔用率不超70%。以上指標都符合期待值，那麼通過提取這些關鍵數據就可以記錄下來，作爲測試的準出標準
二、如何快速定位到性能閾值 eg:每秒處理事務數達到最理想的值，有沒有什麼技巧？
答：對於一個新的壓測單元，建議先設置一個線程數較小的初始值，逐漸增加線程數來觀察事務的處理能力的變化。直到達到性能拐點(處理能力下降，響應時間明顯增加)
三、線程數是壓的越多越好嗎？壓到多少線程合理？
答：線程數受壓力產生機的CPU和內存影響較大，並且Jmeter是基於響應原理工作(一個線程在發出請求並得到應答後纔會繼續發出下一個請求。)舉個例子，jmeter(單臺)不能在服務器只能處理100個請求每秒的情況下，提供200QPS的壓力，一般情況下建議不超過500，默認從100線程開始施壓，根據實際處理能力來調整線程數大小
四、壓測持續時間長短有什麼區別？壓測持續時間長，保證效果更接近期望值？設置壓測時間較短時的目的是什麼，爲了測高併發？
答：這個問題好比一個問卷調差，你調查的範圍越大，取樣更廣泛得出的結論才更接近平均值(統計年收入，結果只統計了張三跟馬雲)。一般情況下衡量單個接口的指標，時間不需要太長,因爲涉及大量的數據讀寫操作，但至少不低於5分鐘。如果能保證長時間運行穩定的情況下，取樣時間可以相對減小
五、平均響應時間爲什麼越隨着時間的增長，越來越長？除了隊列阻塞，還有其他原因嗎？
答：大多數情況下是服務端的處理能力下降導致，在較大壓力下,CPU和內存資源長時間被佔用無法釋放
六、性能測試通常需要反覆測試幾輪才能達到預期的結果，有沒有硬性標準？
答：完成變更(優化)後計劃所列出的各項測試內容；測試結果穩定，數值無較大浮動（一般適用於最後一輪，已無優化空間）
七、測試環境是否存在網絡瓶頸如何確認？
答：一般情況下需要壓測機和服務器在同一局域網內，走內網帶寬，如果走外網很容易達到網絡瓶頸。
a. 找運維人員或機器所屬負責人進行確認。
b. 直接複製文件傳輸到另一臺服務器 查看網速是否達到內網帶寬上限
（scp -r -P 端口號 [email protected]：/root/
如內網帶寬爲100M時，可傳輸的最大網速爲 12M/s 左右。
如傳輸速率只是2M/s以下 可能不在同一網段，一般也滿足不了壓測傳輸對網速的要求）
八、我們怎麼選擇性能壓測工具
【Loadrunner】
商用，支持各種協議，例如http，tcp，ftp等
支持多種併發模型，C腳本本身性能較高
臃腫，麻煩
【Jmeter】
開源、使用方便
基於Java，可擴展，支持模型較單一。本身性能受限於同步等待以及java本身
比較靈活，可以自己編寫符合自己要求的腳本，二次開發更適合我們服務端測試
【其他】
Apache bench：工具小巧簡單，上手學習較快
Wrk ：性能超級強，某些bench測試使用(https://github.com/wg/wrk)
Grinder python
還有很多。。。
具體使用結合公司項目以及自己的優勢來選擇，我個人喜歡用jmeter
待更新