Java 應用發佈後，須要關注的7個性能指標

在某個重大發布以後，都須要記錄相應的指標，本文介紹了最重要的幾個 Java 性能指標，包括響應時間和平均負載等。爲理解應用程序在生產環境中如何運行，就須要遵循一些 Java 性能指標。

在之前，當軟件被髮布後，開發者是沒有方法去了解它在生產環境中的運行狀況；而如今，幾乎任一個你能夠想到的指標均可以被監測和報告。時下，開發者面臨的問題並非缺少信息，而是信息過載、過大。所以在數百臺服務器同時工做的情景下，跟蹤記錄信息就變得愈來愈困難，雖然多數開發者爲了深入理解產品系統仍舊須要利用日誌文件，但依然阻擋不了它們逐步被取代的命運。

本文整理了一些重要的指標，使開發者在不借助任何日誌文件的狀況下，便於理解應用程序在生產環境中運行的具體過程。談到對 Java 性能的影響，除了像用戶負載（或者 AWS 雲服務器停機）這樣的外部因素，新功能發佈多是最多見的誘因。因此在那些新功能發佈以後的敏感時段，遵循相應準則變得更爲關鍵。

數字至上

在逐個討論指標以前，先來強調一個重要問題。有這樣一個觀點：若是某個觀點能夠獲得數字支持，那麼它必定是毋庸置疑的。可是這裏存在的問題是，當給你呈現時，不少因素會歪曲你對數據的理解。這麼說可能有點抽象，這裏能夠對比這兩個測量用例：首先，在一個簡單的時間序列中，觀察某一個特定基本指標如何隨着時間推移而變化；其次，從不一樣的角度觀察數據，並保存關注的性能百分比，底線就是必定要關心留意的那個指標所產生的影響，並給以完整性檢查以便對其評估。

例如，假設咱們正在觀察中值/50百分點處的事務響應時間，由於該點的響應時間已被普遍用做指示符，不少公司將其做爲主要KPI之一。在實際中，若單個頁面瀏覽人數達到幾十及以上（通常遠遠超過40），就意味着該用戶有99.999...%的可能會經受比中值更差的結果（數學公式可簡單的表示爲：1 –（0.5 ^ 40） 。所以什麼百分點更有意義呢？即便觀察點設在第95的百分點，而後你的單頁面瀏覽人數遠大於40，那麼大部分的用戶仍會經受比以前更糟糕的響應時間。若符合多個頁面瀏覽量，事情會更加複雜。想閱讀更多關於百分點的知識，瞭解其對數據的誤導，可點擊此處進入Gil Tene 的博客。

家下來咱們來仔細解讀指標的選擇，看看它們各自表明什麼，並學習如何來理解這些指標。

1. 響應時間與吞吐量

響應時間用來衡量應用程序中的事務處理速度，它也能夠從 HTTP 請求層和數據庫層來觀察。有些最慢的查詢須要最優化解決，而響應時間能夠縮小該查詢的範圍。吞吐量從另外一個角度觀察處理過程，並顯示應用程序在給定時間域中處理多少請求，一般單位爲每分鐘（cpm）。

測量響應時間的方法之一就是使用像 New Relic 或者 AppDynamics（就是曾在之前的博客討論的）那種 APM（應用性能監控工具），經過這些工具，能夠追蹤平均響應時間，並能夠直接在主報告儀表板上與昨日或者上週的平均響應時間做比較，這些比較有助於查看新的部署如何對應用程序形成了影響。另外一種方法是經過測量網頁處理的百分位數，來測量 HTTP 請求完成響應所需的時間。

也能夠內部監測響應時間，可是須要硬代碼，例如經過 Dropwizard 指標發送數據並在 Graphite 上發佈。儘管看來將這些數據和其餘標準關聯時會出現最有用的看法，但更多的看法仍涵蓋在接下來的方法中。

要點1: 確保所使用的採集方法能夠實現從不一樣角度觀測數據，並開始進入百分位層面。

可行工具：

1. AppDynamics

2. New Relic

3. Ruxit

4. OneAPM

圖爲 OneAPM 上監控到的 Java 應用程序響應時間和吞吐量

2. 平均負載

第二個普遍使用的衡量指標就是服務器的平均負載。平均負載習慣上分紅3部分，在最後的一、5和15分鐘（從左到右）顯示其結果。只要分數低於機器內核的數量，就是無壓力狀態，一旦超過內核數，就意味着機器處於壓力狀態。

平均負載除了能夠簡單測量 CPU 利用率，更着重於考量每一個內核目前在隊列中有多少進程。某內核利用率達100%，可是卻即將結束任務，而另外一內核在隊列中還有6個進程要處理，這兩種狀況是大相徑庭的。CPU 這一律念並無涵蓋其區別，可是平均負載卻能夠從大局中考慮此問題。

若在 linux 系統上跟蹤平均負載狀況，一個極好的方式就是經過 Hisham Muhammad 利用 htop 完成。豐富的色彩加上生動的視覺化效果，瞬間使得命令行有了 NASA 儀表板的即視感。

要點2： 要肯定負載，僅靠資源利用率是不夠的，還須要格外注意以便充分了解隊列中的進程。

可行工具:

1. htop

圖爲在一臺服務器上運行 htop 以檢測負載，平均負載顯示在界面的右上角。

3. 錯誤率（及如處理）

錯誤率觀測有多種方法，而多數開發人員都利用高層次標準——在整個應用層考察錯誤率，好比在全部 HTTP 請求中考察失敗的 HTTP 處理總數。可是還有一個常常被忽視的具體點：特定事務的錯誤，這與應用程序的運行情況有直接的影響。代碼中某一特定方法失敗、生成日誌錯誤及發生異常的次數佔總調用次數的比重，也要予以顯示。

圖爲 OneAPM 對事務中的錯誤率監控，隨時間監控應用錯誤率狀況。

可是這些數據對其自己並無太大的意義。第一步，從正在處理的事件中優選出最緊急的一件，找到日誌錯誤或異常；第二步，從實際根源處着手，並予以修復。並且基於此問題，已有相應的解決辦法。有了 OneAPM ，就沒有必要根據日誌文件去找錯誤提示，由於關於服務器狀態的全部信息都會在同一界面顯示，包括堆棧蹤影、實源代碼、變量值及每一個錯誤調用的應用實例。

要點3： 要解決錯誤率增加的根本緣由，僅靠日誌文件是不夠的，爲了獲得大量關於咱們所需指標的數據，還須要利用一些錯誤率監控工具。

4. GC率和停止時間

垃圾回收器行爲異常，是致使應用吞吐量和響應時間忽然降低的主要緣由之一。讀者想要了解關於垃圾回收過程的更多知識和相關的標準，可閱讀 深刻理解Java虛擬機（第2版）。

分析 GC 日誌文件是理解 GC 停止時間和頻率的關鍵。若是不自行分析，或者使用相似於 jClarity 的工具，這種指標是沒有辦法直接使用的。因此要確保使用合適的 JVM 參數打開 GC 日誌採集，以便分析。

要點4： 請記住，分析不一樣指標的相關數據，要保持開闊的思惟，這樣容易發現它們之間的互相影響。

可行工具:

1. jClarity Censum

2. GCViewer

5. 業務指標

應用的性能不是僅僅依賴於快速響應，也非錯誤率，另外一個方面就是業務指標。其業務責任也不是隻由產品/銷售人員全權負責。收入、用戶數、與應用中特定區域的互動等，這些都對理解軟件的運行極爲關鍵。若要從業務角度觀察，你所配置的修復方法和新功能是如何影響底線的，以上因素與新部署的時間標記一塊兒做用這一點相當重要。咱們當然但願狀況向好的方向發展，但假如事態惡化，一旦你把全部數據都存在同一位置，要想知道哪裏出了問題須要修復，這就至關容易了。

此外，將業務指標與錯誤率、延時等數據實時鏈接起來，這種能力是極有力度的。而後會讓人情不自禁地深刻研討究竟是什麼錯誤或異常形成了此次最主要的問題，接着就能夠按照對業務目的影響優先考慮它們。想要搞清楚遍及各處的全部異常及日誌錯誤，就得使用集成開放的監測工具。因此，保持數據開放，使其能夠輸出到選擇服務中，這是極其重要的。

假如你要利用 Graphite 將彙報的業務指標集中化，這就要求你所使用的工具對發送數據開放。例如，咱們的工程組就將彙報指標經過 StatsD 發佈出來，所以相應數據就能夠指向任一用戶選擇使用的儀表板上。

要點5： 先入先出式數據已經是過去式，在使用指標時，也須要讓它們和其餘來源的數據相關聯。

可行工具:

1. Grafana

2. The ELK stack

3. Datadog

4. Librato

6.正常運行時間和服務運行情況

該指標爲總體的工做定下基調。除用做警示媒介外，它還可用於在一段時間內自定義 SLA，以便觀察當爲用戶提供功能完備的服務時所用時間的百分比。

咱們經過運行使用 servlet 的 Pingdom 來解決這個問題，它會對全部應用程序事務中參與的服務進行檢查，包括數據庫和 S3 等。

要點6： 正常運行時多是二進制指標，可是經過聚合多個值的方式在堆棧中定位薄弱點。

可行工具:

1. Pingdom

圖爲用 Pingdom 監測正常運行時和應用運行情況。

7.日誌規模

以上討論到的指標除了 GC 都沒有提到日誌，但這個仍然不可忽略。日誌文件的反作用就是它們一直在增加，若是不留意其大小以及抑制，那麼後果不堪設想。當日志不受控制，磁盤驅動器極可能被撐爆，服務器中會充斥着垃圾文件，運行緩慢，所以，必定要密切關注日誌規模，不然隨時會崩潰。

一個普遍使用的解決辦法就是，使用 logstash 等將服務器上的日誌分塊，再將其送入Splunk、ELK 等其餘日誌管理工具中存儲，或者直接簡單地存入 S3。另外一種方法就是在某一時間將日誌文件翻轉再截斷，但此法要冒信息丟失的風險。和大部分開發人員同樣，目前咱們還必須依賴於日誌。

要點7： 日誌會給人帶來很大的困擾，尤爲是當你用某些外部服務來處理日誌時，你會被 GB 指控。這時就要從新考慮一下這個問題，還應該開始下降日誌大小。

最後的思考

咱們能夠看到這一趨勢：目前在產品中，應用裏的數據採集器正逐漸脫離對日誌文件的依賴。軟件分析的新世界愈來愈開放，數據更加智能化，已再也不是之前枯燥的數字，而是帶有豐富的情境。咱們很興奮地看着世界的改變，並期待和大家一塊兒共建嶄新的將來。

原文地址：https://dzone.com/articles/7-java-performance-metrics-to-watch-after-a-major-1