1 什么是性能指標？

性能指標：任務或系統運行過程中，應用某些評估技術和指標，以評估其運行情況或表現的性能有多好的一種衡量方式。

這里我總結了七個影響最大的指標來衡量系統的性能。

2 七大性能指標

2.1 平均負載

對于 平均負載 指標，通常我們用三階段法來監測：第5分鐘、第15分鐘、最后一分鐘。

當然這個三階段監測法有一個前提，那就是應用數量必須低于機器的內核數量。很好理解，當你應用數都超過了機器的內核數了，整個服務器處于高壓狀態運行，自然這個監測方法也沒有什么意義了。

通常我們監測服務器，比如從服務器的 CPU 使用情況、內核隊列的線程情況。舉個簡單的例子，如果 CPU 使用率達到了百分百，內核隊列只有1個線程任務和又10個線程任務是不同的。因此平均負載不能只考慮服務器 CPU 的使用率。

對于 平均負載監測工具，這里推薦使用：htop。

2.2 業務指標

其實很多公司對于應用程序的性能大多歸于 應用的響應時間 以及 應用的錯誤率。其實這樣是不正確的，雖然應用的響應時間和錯誤率也是衡量應用性能的一些標準，實際業務指標也是衡量應用性能的指標之一，比如：應用帶來的收益、用戶量、交易量等。

對于 業務指標監測工具，這里推薦使用：Grafana、The ELK stack、Datadog、Librato。

2.3 GC率和暫停時間

作為JAVA開發者的都知道，JVM有它自己的一些垃圾回收機制，其實垃圾回收器本身的吞吐量和響應時間也會給我們的業務程序的性能帶來重要的影響。

因此了解并熟悉JVM的GC的機制原理，通常通過GC的日志文件來分析GC暫停的頻率和持續時間，當然還需要JVM參數來作為參考。

同時合理的選用GC回收器以及GC參數配置，也會極大應用的優化性能。

對于 GC率和暫停時間監測工具 ，這里推薦使用：jClarity Censum、GCViewer。

2.4 錯誤率

對于錯誤率，我們可以從兩個方面來判斷：

1、根據HTTP傳輸總失敗的百分比來判斷錯誤率。

2、根據HTPPT特定傳輸的錯誤率。

因此在實際生產中，絕大多數開發者僅僅根據HTPP傳輸總失敗的百分比來判斷錯誤率是不對的，他們往往會忽略特定傳輸的錯誤率，其實對特定傳輸的錯誤率監測可以更好的看出你的應用程序運行狀況，可以顯示出代碼方法的具體錯誤或者異常的次數。

實際在生產中單純的錯誤率對我們是沒有什么風用處的，頂多說可以拿著數據來分析應用的錯誤概率。實際上更重要的是從根源上去解決這些錯誤。

對于 錯誤率監測工具 ，這里推薦使用：Takipi。

可以在 Takipi 的日志文件中找到線索。比如服務器的運行狀態【包括堆棧跟蹤、源代碼和變量值查看】

2.5 響應時間和吞吐量

通常應用程序的接口響應時間就可以大概知道程序完成處理需要的時間，這樣就可以對特定的接口業務代碼進行優化或者對數據庫SQL慢查詢優化【一方面走程序層面優化，另一方面可走數據庫層面優化】來縮短響應時間。

吞吐量是另一個角度衡量傳輸數據的指標，是指單位時間內系統處理的客戶請求的數量。

因此對于響應時間和吞吐量 指標 我們可以用APMs來衡量，可以在著報告儀表盤中把平均響應時長和歷史響應時長進行對比，然后來作為分析的依據。

對于 響應時間和吞吐量監測工具 ，這里推薦使用：AppDynamics、New Relic、Ruxit。

可以幫助我們觀察新的部署對應用程序有沒有什么影響。還可以監測到網絡傳輸的百分比，測量HTTP完成請求需要多長時間。

New Relic 工具的報告，可以監測Web傳輸百分比和吞吐量。

2.6 日志大小

應該都知道，linux服務發布的應用，它的日志大小會隨著時間越長增加的越來越大，如果你的服務器堆滿了日志文件，磁盤占用過大，那么服務器運行的性能肯定大打折扣，什么都慢下來了。

對于JAVA程序啟動時我們可以設置日志按天打印并打壓縮包，對于過于時間長久的日志可以定時遷移到專門的文件存儲中去，或者線下管理。

目前通常的解決辦法是使用logstash劃分使用日志，并將它們發送并存儲在Splunk、ELK等日志管理工具中。

對于 日志大小監測工具 ，這里推薦使用：Splunk、Sumo Logic、Loggly。

2.7 服務運行狀態和正常運行時間

服務運行狀態和正常運行時間指標，直接就能奠定我們的應用程序性能的基礎，不僅可以當做一個提醒指標，也可以讓你定義一段時間內的SKA。

通常可以用Pingdom的Servlet功能進行運行狀態監測。七種應用的所有傳輸【如數據庫和S3】都可以查看到。

對于 服務運行狀態和正常運行時間工具 ，這里推薦使用：Pingdom。