摘要: 在這篇文章中，你將會了解到為什么常見的主要測試指標是不完美的，以及十個新的測量指標 —— 它們可能會改進你未來的性能測試報告。
性能測試是一項不可避免的任務，但問題是怎么保證測試的指標是正確且合理的？在這篇文章中，你將會了解到為什么常見的主要測試指標是不完美的，以及十個新的測量指標 —— 它們可能會改進你未來的性能測試報告。
在很多企業中，性能測試是定期進行的。作為這些測試的一部分，質量保證團隊會收集各種指標并將其發布在性能測試報告中。性能測試報告中常用的一些分析指標是 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 和抓取性能數據的目的，以幫助分析系統的總體結構以及分布式應用程序的組件之間是如何進行數據互聯的。
參考：jaxenter
