您好,登錄后才能下訂單哦!
這篇文章主要介紹“Java程序員必須清楚的性能指標是什么”,在日常操作中,相信很多人在Java程序員必須清楚的性能指標是什么問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”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
到此,關于“Java程序員必須清楚的性能指標是什么”的學習就結束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續學習更多相關知識,請繼續關注億速云網站,小編會繼續努力為大家帶來更多實用的文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。