java應(yīng)用性能指標(biāo)

再想一想。

性能和可靠性相關(guān)嗎？ 還是這些東西相互排斥？ 我認(rèn)為是后者。 如今，現(xiàn)實是IT部門將應(yīng)用程序的性能和可靠性視為同一事物，但這離事實還差得遠(yuǎn)。

讓我們看看一級方程式車隊如何管理性能和可靠性。

上賽季邁凱輪本田車隊既慢又不可靠。 法拉利本賽季在排位賽中表現(xiàn)很快，但是在比賽中并不可靠。 另一方面，梅賽德斯在過去的兩年中一直超級敏捷，超級可靠，這讓所有人都望而卻步。

性能

F1賽車通常受以下三個因素影響：動力單元，發(fā)動機映射和空氣動力阻力/下壓力。

引擎圖指示了動力單元從可用資源（空氣，燃料和電力）中消耗了多少資源。 空氣動力阻力/下壓力由汽車周圍的氣流管理方式?jīng)Q定。

更大的功率和更低的阻力意味著更少的阻力，更快的加速度和更高的頂端速度。

下壓力越大，拐角處的抓地力/速度越大。 性能就是F1賽車在賽道上跑得有多快。 F1車隊在一個典型的周末將對汽車的設(shè)置進(jìn)行數(shù)百次更改，希望每十分之一秒都能解鎖一次，這樣他們就可以超越排位賽并參加比賽。

同樣，應(yīng)用程序性能受三件事影響：JVM運行時，應(yīng)用程序邏輯和事務(wù)流。

應(yīng)用程序邏輯消耗了JVM運行時的資源（線程，cpu，內(nèi)存等），并且事務(wù)流由每個事務(wù)必須跨越基礎(chǔ)結(jié)構(gòu)組件或第三方Web服務(wù)進(jìn)行的躍點數(shù)決定。

性能與計時最終用戶請求（頁面/事務(wù)）以及了解應(yīng)用程序邏輯和事務(wù)流之間的端到端延遲有關(guān)。 像F1工程師這樣的開發(fā)人員將進(jìn)行數(shù)百項更改，希望優(yōu)化最終用戶體驗，從而使業(yè)務(wù)受益。

性能的主要度量單位是響應(yīng)時間，因此，在管理此性能時，諸如AppDynamics，New Relic和Dynatrace之類的Application Performance Monitoring（APM）解決方案是頭等大事。

可靠性

F1賽車通常受其工程組件，賽車ECU和百萬傳感器輸入，參數(shù)和功能的質(zhì)量影響。

一些意外參數(shù)，賽車將立即停止。 去年，尼科·羅斯伯格（Nico Rosberg）兩次發(fā)生事故，當(dāng)時他的方向盤和電子設(shè)備停滯不前。

對F1汽車的性能進(jìn)行故障診斷與對其可靠性進(jìn)行故障診斷有很大不同，它們是有些不同的用例，需要不同的遙測，工具和觀點。 可靠性是關(guān)于了解事情為什么破裂以及事情為什么運行緩慢的原因。

對應(yīng)用程序的處理相同，只是當(dāng)應(yīng)用程序崩潰時，這是因為應(yīng)用程序邏輯在某處發(fā)生故障，從而引發(fā)了錯誤或異常。 這與運行緩慢的應(yīng)用程序邏輯有很大不同。

應(yīng)用程序邏輯接受輸入，對其進(jìn)行處理并創(chuàng)建某種輸出。 與F1賽車一樣，應(yīng)用程序具有成千上萬個具有數(shù)百萬行代碼的組件（功能），每個代碼行可同時處理數(shù)十萬個參數(shù)（對象和變量）。 沒有可靠性，性能無關(guān)緊要。 日志文件是錯誤和異常所在的地方。

問題：慢航班搜索比航班預(yù)訂錯誤重要嗎？

答案：它們都會殺死企業(yè)，因此您需要同時管理兩者。

航班預(yù)訂失敗

歡迎來到廢話數(shù)據(jù)世界

假設(shè)這些APM解決方案在管理性能方面做得很好。 我們的行業(yè)仍然堅信，日志文件（或某些供應(yīng)商稱之為大數(shù)據(jù)）是理解應(yīng)用程序失敗原因的答案。 我實際上將這種方法稱為“廢話數(shù)據(jù)”。

日志文件缺乏深度，上下文和洞察力，對于任何真正想找到應(yīng)用程序故障的真正根本原因的人來說。 當(dāng)然，日志文件總比沒有好，但是讓我們看一下開發(fā)人員需要哪些數(shù)據(jù)才能始終找到根本原因：

應(yīng)用程序堆棧跟蹤 –顯示哪個應(yīng)用程序組件（類/方法）是故障的一部分

應(yīng)用程序源代碼 –顯示導(dǎo)致失敗的代碼行

應(yīng)用程序狀態(tài) –顯示組件/源代碼處理的應(yīng)用程序參數(shù)（對象，變量和值）

今天，大多數(shù)日志文件將包含數(shù)百萬個重復(fù)的應(yīng)用程序堆棧跟蹤。 這就是Splunk之所以價值60億美元的原因，因為每條重復(fù)的堆棧跟蹤信息都會花費$$$來解析，索引，存儲和搜索。

是的，開發(fā)人員可以自定義應(yīng)用程序日志以將所需的任何數(shù)據(jù)放入其中。 壞消息是，由于開銷，開發(fā)人員無法記錄所有內(nèi)容，而創(chuàng)建有意義的日志通常需要知道將在應(yīng)用程序中破壞什么。

沒有水晶球，就不可能創(chuàng)建有效的日志文件，這就是為什么團隊仍然要花費數(shù)小時或數(shù)天來尋找大海撈針的原因。 沒有應(yīng)用程序源代碼或狀態(tài)意味著操作和開發(fā)必須猜測。 這不好。 不幸的是，堆棧跟蹤是不夠的。 在F1中，這就像梅賽德斯維修站工作人員告訴他們的工程師“我們的遙測技術(shù)剛剛確認(rèn)Nico的方向盤壞了，這是我們僅有的遙測技術(shù)–您能找出原因并盡快修復(fù)它”。

您能想象工程師會怎么想嗎？ 不幸的是，這是大多數(shù)開發(fā)人員今天在得知應(yīng)用程序出現(xiàn)故障時的想法。

好消息是，現(xiàn)在可以知道生產(chǎn)中何時以及為何中斷應(yīng)用程序代碼。 歡迎來到塔基皮 。

現(xiàn)在，不可能的事情成為可能，并且日志文件到此結(jié)束。

翻譯自: https://www.javacodegeeks.com/2016/04/performance-vs-reliability-java-apps-like-f1-cars.html

java應(yīng)用性能指標(biāo)

總結(jié)

以上是生活随笔為你收集整理的java应用性能指标_性能与可靠性：Java应用为何像F1汽车的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。