再想一想。

性能和可靠性相关吗？ 还是这些东西相互排斥？ 我认为是后者。 如今，现实是IT部门将应用程序的性能和可靠性视为同一事物，但这离事实还差得远。

让我们看看一级方程式车队如何管理性能和可靠性。

上赛季迈凯轮本田车队既慢又不可靠。 法拉利本赛季在排位赛中表现很快，但是在比赛中并不可靠。 另一方面，梅赛德斯在过去的两年中一直超级敏捷，超级可靠，这让所有人都望而却步。

性能

F1赛车通常受以下三个因素的影响：动力单元，发动机映射和空气动力阻力/下压力。

引擎图指示了动力单元从可用资源（空气，燃料和电力）中消耗了多少资源。 空气阻力/下压力取决于如何控制汽车周围的气流。

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

下压力越大，拐角处的抓地力/速度越大。 性能主要取决于F1赛车在赛道上的跑速。 F1车队在一个典型的周末将对赛车的设置进行数百次更改，希望每十分之一秒都能解锁一次，这样他们就可以超越排位赛并参加比赛。

同样，应用程序性能受三件事影响：JVM运行时，应用程序逻辑和事务流。

应用程序逻辑消耗了JVM运行时的资源（线程，cpu，内存等），而事务流则取决于每个事务必须跨基础结构组件或第三方Web服务进行的跃点数。

性能与计时最终用户请求（页面/事务）以及了解应用程序逻辑与事务流之间的端到端延迟有关。 像F1工程师这样的开发人员将进行数百项更改，希望优化最终用户体验，从而使业务受益。

性能的主要衡量单位是响应时间，因此，在管理此应用程序时，诸如AppDynamics，New Relic和Dynatrace之类的Application Performance Monitoring（APM）解决方案是头等大事。

可靠性

F1赛车通常受其工程组件，赛车ECU和百万传感器输入，参数和功能的质量影响。

一些意外参数，赛车将立即停止。 去年，尼科·罗斯伯格（Nico Rosberg）两次发生事故，当时他的方向盘和电子设备停滞不前，尽管拥有最快的赛车，但所有这些。

对F1汽车的性能进行故障诊断与对其可靠性进行故障诊断有很大不同，它们是有些不同的用例，需要不同的遥测，工具和观点。 可靠性是关于了解事物为何破裂以及事物运行缓慢的原因。

对应用程序的处理相同，只是当应用程序崩溃时，这是因为应用程序逻辑在某处发生故障，从而引发了错误或异常。 这与运行缓慢的应用程序逻辑有很大不同。

应用程序逻辑接受输入，对其进行处理并创建某种输出。 像F1赛车一样，应用程序具有成千上万个组件（功能）和数百万行代码，每个代码可随时处理数十万个参数（对象和变量）。 没有可靠性，性能无关紧要。 日志文件是错误和异常所在的地方。

问题：慢航班搜索比航班预订错误重要吗？

答案：它们都会杀死企业，因此您需要同时管理两者。

欢迎来到废话数据世界

假设这些APM解决方案在管理性能方面做得很好。 我们的行业仍然坚信，日志文件（或某些供应商称之为大数据）是理解应用程序为何失败的答案。 我实际上将这种方法称为“废话数据”。

日志文件缺乏深度，上下文和洞察力，对于任何真正想要找到应用程序故障的真正根本原因的人来说。 当然，日志文件总比没有好，但让我们看看开发人员需要什么数据才能始终找到根本原因：

1. 应用程序堆栈跟踪 –显示哪个应用程序组件（类/方法）是故障的一部分
2. 应用程序源代码 –显示导致失败的代码行
3. 应用程序状态 –显示组件/源代码处理的应用程序参数（对象，变量和值）

今天，大多数日志文件将包含数百万个重复的应用程序堆栈跟踪。 这就是Splunk之所以价值60亿美元的原因，因为每条重复的堆栈跟踪信息都会花费$$$来解析，索引，存储和搜索。

是的，开发人员可以自定义应用程序日志以将所需的任何数据放入其中。 坏消息是，由于开销，开发人员无法记录所有内容，而创建有意义的日志通常需要知道将在应用程序中破坏什么。

没有水晶球，就不可能创建有效的日志文件，这就是为什么团队仍然要花费数小时或数天来寻找大海捞针的原因。 没有应用程序源代码或状态意味着操作和开发必须猜测。 这是不好的。 不幸的是，堆栈跟踪是不够的。 在F1中，这就像梅赛德斯维修站工作人员告诉他们的工程师“我们的遥测技术刚刚确认Nico的方向盘坏了，这是我们仅有的遥测技术–您能找出原因并尽快修复它”。

您能想象工程师会怎么想吗？ 不幸的是，这是大多数开发人员今天在得知应用程序出现故障时的想法。

好消息是，现在可以知道生产中何时以及为何中断应用程序代码。 欢迎来到塔基皮 。

现在不该有可能了，这就是日志文件的结尾。

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