再想一想。

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

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

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

性能

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

引擎圖指示了動力單元從可用資源（空氣，燃料和電力）中消耗了多少資源。 空氣阻力/下壓力取決于如何控制汽車周圍的氣流。

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

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

同樣，應用程序性能受三件事影響：JVM運行時，應用程序邏輯和事務流。

應用程序邏輯消耗了JVM運行時的資源（線程，cpu，內(nèi)存等），而事務流則取決于每個事務必須跨基礎結(jié)構(gòu)組件或第三方Web服務進行的躍點數(shù)。

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

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

可靠性

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

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

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

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

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

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

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

航班預訂失敗

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

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

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

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

應用程序源代碼 –顯示導致失敗的代碼行

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

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

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

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

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

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

現(xiàn)在不該有可能了，這就是日志文件的結(jié)尾。

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

總結(jié)

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

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