有的放矢，你應該在性能測試報告中使用的 10 個微觀指標

在這篇文章中，你將會了解到爲何常見的主要測試指標是不完美的，以及十個新的測量指標 —— 它們可能會改進你將來的性能測試報告。

性能測試是一項不可避免的任務，但問題是怎麼保證測試的指標是正確且合理的？在這篇文章中，你將會了解到爲何常見的主要測試指標是不完美的，以及十個新的測量指標 —— 它們可能會改進你將來的性能測試報告。

在不少企業中，性能測試是按期進行的。做爲這些測試的一部分，質量保證團隊會收集各類指標並將其發佈在性能測試報告中。性能測試報告中經常使用的一些分析指標是 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，裏面大牛已經爲咱們整理好了許多的學習資料，有自動化，接口，性能等等的學習資料！人生是一個逆水行舟的過程，不進則退，我們一塊兒加油吧！