Java生鮮電商平台-電商系統性能指標
1.響應時間和吞吐量
根據應用程序的響應時間可以知道程序完成傳輸數據所用的時間。也可以從HTTP請求級別，或者成為數據庫級別來看。對那些緩慢的查詢你需要做一些優化來縮短時間。吞吐量是另一個角度衡量傳輸數據的指標，是指單位時間內系統處理的客戶請求的數量。
我們可以使用APMs（例如New Relic或AppDynamics）來衡量這些指標。使用這些工具，你可以在主報告儀表板中將平均響應時間與昨天的甚至上周的直接進行對比。這有助於我們觀察新的部署是否會影響到我們的應用程序。你可以看到網絡傳輸的百分比，測量HTTP完成請求需要多長時間。你也可以看看這篇：網站性能測試指標（QPS，TPS，吞吐量，響應時間）詳解。
推薦工具：
AppDynamics
New Relic
Ruxit
New Relic報告：Web傳輸百分比和吞吐量
2.平均負載
第二個應用廣泛的指標是平均負載。我們習慣上會把平均負載分為這三步測量，分別是第5分鍾、第15分鍾和最后1分鍾。要保證數量低於機器的內核數。一旦超過內核數，機器就會運行在壓力狀態下。
除了簡單測量CPU使用率，還需要關注每個內核的隊列中有多少進程。在內核使用率都是100%的情況下，隊列中只有1個任務和有6個任務有很大不同。因此，平均負載不能只考慮CPU使用率。
推薦工具：
htop
3.錯誤率
大多數開發人員判斷錯誤率是根據HTTP傳輸總失敗百分比。但是他們忽略了一個更深層的東西：特定傳輸的錯誤率。這直接影響到您應用程序的運行狀況。這可以顯示出代碼方法的錯誤以及錯誤或異常出現的次數。
但單純的錯誤率數據對我們沒有多大幫助。最重要的是我們要找到它們的根源並解決問題。隨着Takipi的運行，我們要在日志文件中需找線索。你可以找到所有關於服務器狀態的信息，包括堆棧跟蹤、源代碼和變量值。
推薦工具：
Takipi
4.GC率和暫停時間
異常行為垃圾收集器應用程序的吞吐量和響應時間采取深潛的主要原因之一。了解GC暫停頻率和持續時間的關鍵是分析GC日志文件。要分析它們，你需要收集GC日志和JVM參數。你要注意觀察不同指標之間的數據是如何相互影響的。
推薦工具：
jClarity Censum
GCViewer
5.業務指標
應用程序的性能不完全取決於響應時間和錯誤率。業務指標也是一方面，例如收益、用戶數。
推薦工具：
Grafana
The ELK stack
Datadog
Librato
6.正常運行時間和服務運行狀態
這一指標奠定了整個應用程序性能的基礎。不僅可以當做一個提醒指標，也可以讓你定義一段時間內的SKA。我們可以使用Pingdom的servlet功能進行運行狀態檢查。我們可以查到應用程序的所有傳輸，包括數據庫和S3。你也可以看看這篇：SLA服務可用性4個9是什么意思？怎么達到？
推薦工具：
Pingdom
7.日志大小
日志有一個缺點，它是一直在增加的。當您的服務器啟動塞滿了垃圾，一切都慢下來。因此，我們需要密切的關注日志大小。
目前通常的解決辦法是使用logstash划分使用日志，並將它們發送並存儲在Splunk、ELK或其他的日志管理工具中。
推薦工具：
Splunk
Sumo Logic
Loggly