引用 陳皓 大大 https://coolshell.cn/articles/17381.html

如何嚴謹地做效能測試
一般來說，效能測試要統一考慮這麼幾個因素：Thoughput吞吐量，Latency響應時間，資源利用（CPU/MEM/IO/Bandwidth…），成功率，系統穩定性。

下面的這些效能測試的方式基本上來源自我的老老東家湯森路透，一家做real-time的金融資料系統的公司。

一，你得定義一個系統的響應時間latency，建議是TP99，以及成功率。比如路透的定義：99.9%的響應時間必需在1ms之內，平均響應時間在1ms以內，100%的請求成功。

二，在這個響應時間的限制下，找到最高的吞吐量。測試用的資料，需要有大中小各種尺寸的資料，並可以混合。最好使用生產線上的測試資料。

三，在這個吞吐量做Soak Test，比如：使用第二步測試得到的吞吐量連續7天的不間斷的壓測系統。然後收集CPU，記憶體，硬碟/網路IO，等指標，檢視系統是否穩定，比如，CPU是平穩的，記憶體使用也是平穩的。那麼，這個值就是系統的效能

四，找到系統的極限值。比如：在成功率100%的情況下（不考慮響應時間的長短），系統能堅持10分鐘的吞吐量。

五，做Burst Test。用第二步得到的吞吐量執行5分鐘，然後在第四步得到的極限值執行1分鐘，再回到第二步的吞吐量執行5鍾，再到第四步的許可權值執行1分鐘，如此往復個一段時間，比如2天。收集系統資料：CPU、記憶體、硬碟/網路IO等，觀察他們的曲線，以及相應的響應時間，確保系統是穩定的。

六、低吞吐量和網路小包的測試。有時候，在低吞吐量的時候，可能會導致latency上升，比如TCP_NODELAY的引數沒有開啟會導致latency上升（詳見TCP的那些事），而網路小包會導致頻寬用不滿也會導致效能上不去，所以，效能測試還需要根據實際情況有選擇的測試一下這兩咱場景。

（注：在路透，路透會用第二步得到的吞吐量乘以66.7%來做為系統的軟報警線，80%做為系統的硬報警線，而極限值僅僅用來扛突發的peak）

是不是很繁鎖？是的，只因為，這是工程，工程是一門科學，科學是嚴謹的。

上訴的是一個典型案例

效能測試最終的目的一定是為了測試軟體工程能否滿足使用需求，所以測試的角度和結果報告一定是站在這一需求的角度上進行選擇的，如果不能體現出該需求，那麼測試的方式一定是錯誤的。
如穩定性 應該用 TP99 或者TP100 （TP – Top Percentile）指數來證明，同時 指出 極值，以及執行後的趨勢圖，以此來判斷在負載均衡時的資料。

使用ADB 指令 adb shell top 我們也能看到一些用以作為參考的效能指標