效能測試是一項不可避免的任務，但問題是怎麼保證測試的指標是正確且合理的？在這篇文章中，你將會了解到為什麼常見的主要測試指標是不完美的，以及十個新的測量指標 —— 它們可能會改進你未來的效能測試報告。
在很多企業中，效能測試是定期進行的。作為這些測試的一部分，質量保證團隊會收集各種指標並將其釋出在效能測試報告中。效能測試報告中常用的一些分析指標是 CPU 利用率、記憶體利用率，關鍵事務或後端系統的響應時間以及網路頻寬，具體取決於企業自身的情況。
我更願意將這類指標歸類為巨集觀指標，巨集觀指標當然很好，但它們有兩個不可忽視的主要缺點：
- 不能在測試環境中捕獲到效能問題
儘管在測試環境中進行了許多效能測試，但在生產環境中仍然會出現效能下降的情況。在測試環境中，你也許會注意到效能急劇下降的情況，但上面提到的巨集指標並不能幫助你發現問題的根源。這些急劇的下降在生產環境中的體現就是主要的效能問題。下面討論的微觀指標會為這些下降的情況帶來可見性。 - 巨集觀指標對解決問題沒有幫助
在很大程度上，巨集觀指標不能幫助開發團隊除錯和排除故障。例如，如果巨集觀指標顯示 CPU 消耗高，它不能表明這是由於垃圾收集活動、執行緒迴圈問題或其他編碼問題而導致的 CPU 消耗增加。同樣的，如果響應時間下降，也不會有任何指標顯示是由於應用程式程式碼中的鎖定還是後端連線問題而導致的下降。
因此，我的觀點是應將巨集觀指標與微觀指標一起搭配使用。在這篇文章中，將列出十項我認為最重要的微觀指標，你可以考慮將其中的一些或全部新增到你的效能測試報告中。
與記憶體相關的微觀指標
1. 垃圾回收機制的暫停時間
我們應該測量垃圾回收的暫停時間，因為應用程式會在 GC 暫停期間處於被掛起的狀態。這意味著這段時間裡不會執行 customer activity，很顯然這是不好的。降低 GC 暫停時間的數量和長度可直接影響到效能。所以我們應始終力求實現最短的暫停時間。
2. 物件的建立/回收率
建立物件的速度會嚴重影響 CPU 的利用率。如果使用低效的資料結構或程式碼，會生成更多的物件來處理相同數量的事務。過高的物件建立率會導致出現頻繁的垃圾回收行為，而頻繁的 GC 則會增加 CPU 的消耗。
3. 垃圾回收的吞吐量
簡單來說，吞吐量是指應用程式執行緒用時佔程式總用時的比例。 例如，吞吐量 99/100 意味著 100 秒的程式執行時間應用程式執行緒執行了 99 秒， 而在這一時間段內 GC 執行緒只執行了 1 秒。我們應力求實現高吞吐量，即應用程式應執行更多的時間，並減少垃圾回收活動的時間。
4. 每一次生命週期的記憶體消耗
在 JVM、Android Runtime 和其他的平臺中，記憶體會被劃分為幾個內部區域。我們需要知道分配的大小空間以及每個區域的峰值利用率大小。記憶體區域的分配不足會降低應用程式的效能，而超額的分配將增加託管伺服器的成本。
如何獲得與記憶體相關的微觀指標？
所有這些與記憶體相關的微觀指標都可以從垃圾回收日誌中捕獲。
與執行緒相關的微觀指標
5. 執行緒的狀態
執行緒會處於以下的其中一種狀態：新建，可執行，執行中，睡眠，阻塞，等待，死亡。效能測試報告中應體現出每個狀態的執行緒數量。如果執行緒長時間處於阻塞狀態，則應用程式可能會無法響應。如果許多執行緒處於可執行狀態，那麼應用程式的 CPU 消耗就會變高。如果應用程式的執行緒在等待、有時間限制的等待和阻塞狀態中花費更多的時間，這將會降低響應時間。
6. 執行緒組
執行緒組表示一組執行緒的集合。每個應用程式都會被歸屬於多個執行緒組。我們應該測量每個執行緒組的大小並記錄在效能測試報告中。執行緒組大小的增加可能表示著某種型別的效能下降。
7. 守護程式 vs 非守護程式
有兩種型別的執行緒狀態：守護程式和非守護程式（如使用者執行緒）。我們應該按狀態來對執行緒進行報告。因為當非守護執行緒在執行時，JVM 將不會終止。
8. 程式碼執行路徑
應用程式的 CPU、記憶體消耗和響應時間會根據程式碼執行路徑而有所不同。如果大多數執行緒執行特定的程式碼執行路徑，我們應該詳細研究該特定的程式碼執行，以防止出現瓶頸或效率低下的情況。
如何獲得與執行緒相關的微觀指標？
執行緒相關的指標可從執行緒執行緒轉儲中獲得。
與網路相關的微觀指標
9. 出站連結
在當今世界，很少會看到不與其他應用程式通訊的企業應用程式。你的應用程式的效能在很大程度上取決於與它所通訊的應用程式。我們應測量每個端點的 ESTABLISHED 連線數量。連線數量的任何變化都會影響應用程式的效能。
10. 入站連結
應用程式可從多個渠道獲得流量：Web, Mobile, API 和多種協議：HTTP, HTTPS, JMS, Kafka 等等。你需要測量來自每個通道和每個協議的連線數，因為它們也會對應用程式的效能有很大的影響。
如何獲得與網路相關的微觀指標？
應用程式效能監視(APM)工具可以報告此指標，也可以在 APM 工具中配置自定義探針來獲取這些指標的資料。此外，如果不使用 APM 工具，也可以使用 ‘netstat’ 工具。
netstat -an | grep 'hostname' | grep 'ESTABLISHED'複製程式碼這裡推薦三個開源的 APM 工具：
- SkyWalking — 針對分散式系統的 APM 系統，也被稱為分散式追蹤系統，對 Java 分散式應用程式叢集的業務執行情況進行追蹤、告警和分析。
- Zipkin — 推特開源的分散式跟蹤系統，參考了 Dapper 體系。
- Pinpoint — 用 Java 編寫的 APM 工具，用於大規模分散式系統。在 Dapper 之後，Pinpoint 提供了一個解決方案，通過 JavaAgent 的機制來做位元組碼程式碼植入，實現加入 traceid 和抓取效能資料的目的，以幫助分析系統的總體結構以及分散式應用程式的元件之間是如何進行資料互聯的。
跟大家推薦一個學習資料分享群：747981058，裡面大牛已經為我們整理好了許多的學習資料，有自動化，介面，效能等等的學習資料！人生是一個逆水行舟的過程，不進則退，我們們一起加油吧！