java应用性能指标
再想一想。
性能和可靠性相关吗？ 还是这些东西相互排斥？ 我认为是后者。 如今，现实是IT部门将应用程序的性能和可靠性视为同一事物，但这离事实还差得远。
让我们看看一级方程式车队如何管理性能和可靠性。
上赛季迈凯轮本田车队既慢又不可靠。 法拉利本赛季在排位赛中表现很快，但是在比赛中并不可靠。 另一方面，梅赛德斯在过去的两年中一直超级敏捷，超级可靠，这让所有人都望而却步。
性能
F1赛车通常受以下三个因素影响：动力单元，发动机映射和空气动力阻力/下压力。
引擎图指示了动力单元从可用资源（空气，燃料和电力）中消耗了多少资源。 空气动力阻力/下压力由汽车周围的气流管理方式决定。
更大的功率和更低的阻力意味着更少的阻力，更快的加速度和更高的顶端速度。
下压力越大，拐角处的抓地力/速度越大。 性能就是F1赛车在赛道上跑得有多快。 F1车队在一个典型的周末将对汽车的设置进行数百次更改，希望每十分之一秒都能解锁一次，这样他们就可以超越排位赛并参加比赛。
同样，应用程序性能受三件事影响：JVM运行时，应用程序逻辑和事务流。
应用程序逻辑消耗了JVM运行时的资源（线程，cpu，内存等），并且事务流由每个事务必须跨越基础结构组件或第三方Web服务进行的跃点数决定。
性能与计时最终用户请求（页面/事务）以及了解应用程序逻辑和事务流之间的端到端延迟有关。 像F1工程师这样的开发人员将进行数百项更改，希望优化最终用户体验，从而使业务受益。
性能的主要度量单位是响应时间，因此，在管理此性能时，诸如AppDynamics，New Relic和Dynatrace之类的Application Performance Monitoring（APM）解决方案是头等大事。
可靠性
F1赛车通常受其工程组件，赛车ECU和百万传感器输入，参数和功能的质量影响。
一些意外参数，赛车将立即停止。 去年，尼科·罗斯伯格（Nico Rosberg）两次发生事故，当时他的方向盘和电子设备停滞不前。
对F1汽车的性能进行故障诊断与对其可靠性进行故障诊断有很大不同，它们是有些不同的用例，需要不同的遥测，工具和观点。 可靠性是关于了解事情为什么破裂以及事情为什么运行缓慢的原因。
对应用程序的处理相同，只是当应用程序崩溃时，这是因为应用程序逻辑在某处发生故障，从而引发了错误或异常。 这与运行缓慢的应用程序逻辑有很大不同。
应用程序逻辑接受输入，对其进行处理并创建某种输出。 与F1赛车一样，应用程序具有成千上万个具有数百万行代码的组件（功能），每个代码行可同时处理数十万个参数（对象和变量）。 没有可靠性，性能无关紧要。 日志文件是错误和异常所在的地方。
问题：慢航班搜索比航班预订错误重要吗？
答案：它们都会杀死企业，因此您需要同时管理两者。
航班预订失败
欢迎来到废话数据世界
假设这些APM解决方案在管理性能方面做得很好。 我们的行业仍然坚信，日志文件（或某些供应商称之为大数据）是理解应用程序失败原因的答案。 我实际上将这种方法称为“废话数据”。
日志文件缺乏深度，上下文和洞察力，对于任何真正想找到应用程序故障的真正根本原因的人来说。 当然，日志文件总比没有好，但是让我们看一下开发人员需要哪些数据才能始终找到根本原因：
- 应用程序堆栈跟踪 –显示哪个应用程序组件（类/方法）是故障的一部分
- 应用程序源代码 –显示导致失败的代码行
- 应用程序状态 –显示组件/源代码处理的应用程序参数（对象，变量和值）
今天，大多数日志文件将包含数百万个重复的应用程序堆栈跟踪。 这就是Splunk之所以价值60亿美元的原因，因为每条重复的堆栈跟踪信息都会花费$$$来解析，索引，存储和搜索。
是的，开发人员可以自定义应用程序日志以将所需的任何数据放入其中。 坏消息是，由于开销，开发人员无法记录所有内容，而创建有意义的日志通常需要知道将在应用程序中破坏什么。
没有水晶球，就不可能创建有效的日志文件，这就是为什么团队仍然要花费数小时或数天来寻找大海捞针的原因。 没有应用程序源代码或状态意味着操作和开发必须猜测。 这不好。 不幸的是，堆栈跟踪是不够的。 在F1中，这就像梅赛德斯维修站工作人员告诉他们的工程师“我们的遥测技术刚刚确认Nico的方向盘坏了，这是我们仅有的遥测技术–您能找出原因并尽快修复它”。
您能想象工程师会怎么想吗？ 不幸的是，这是大多数开发人员今天在得知应用程序出现故障时的想法。
好消息是，现在可以知道生产中何时以及为何中断应用程序代码。 欢迎来到塔基皮 。
现在，不可能的事情成为可能，并且日志文件到此结束。
翻译自: https://www.javacodegeeks.com/2016/04/performance-vs-reliability-java-apps-like-f1-cars.html
java应用性能指标
