这是系列文章中的最后一篇，我们将分析我们在2014年10月进行的Java Performance Tuning Survey的结果。如果您还没有阅读第一篇文章，我建议您首先阅读以下内容：

• 性能问题的频率和严重性
• 最受欢迎的监控解决方案
• 查找根本原因的工具和技术

这篇文章打开了一些有趣的相关数据，并总结了结果。

复制是快速成功的关键

当您负责解决性能问题时，您需要证据来找到根本原因。 为了获得证据，您通常需要重现问题。 在调查中，我们询问了受访者是否能够重现该问题 ：

• 9％不需要复制，已经有足够的证据
• 27％无法重现该问题
• 64％设法重现了问题

在另一个问题中，我们问“ 找到并解决您面临的问题需要多长时间”。 平均而言，这花费了80个小时 。 我们分析了是否有27％无法重现该问题的人是否还在苦苦挣扎。 结果很明显：

• 如果受访者能够重现问题，则平均需要65个小时
• 如果响应者无法重现该问题，则 需要花费 113个小时或74％的时间才能找到根本原因并加以解决。

区别清晰可见。 造成这种差异的原因隐藏在故障排除过程中。 要解决问题，您需要证据，通常是从各种来源收集的证据，例如日志文件，线程转储或堆转储。 但是，只有能够重现此案（最好随意），您才能获得证据。 如果您无法重现问题，那么您将没有证据，而且武库中唯一的工具往往是良好的旧尝试和错误。 面对超过100,000行代码，您注定会在此过程中面临许多失败的尝试。

有些问题比其他问题要难。

受访者还向我们提供了他们正在解决的性能问题的根本原因。 我们研究了不同的问题，以了解某些问题是否比其他问题更难解决

让我们再次回顾一下，发现和解决问题的平均时间为80个小时。 按问题类型分类时，我们发现了以下内容：

• 查找和修复最简单的问题与网络IO有关：平均花费51个小时。
• 内存泄漏按花费的时间准确地排在平均水平：平均发现并修复一个泄漏要花费80个小时24分钟。
• 另一方面是架构问题–根本原因与整体架构和HTTP会话膨胀有关，分别花费了98 和105个小时。 查找和解决原因的时间增加了大约100％ 。

从极端来看，这实际上并不奇怪。 当您的体系结构引起性能问题时，修复程序本身往往很复杂且耗时，因此需要更多的时间来修复。 而且当您倾向于滥用网络时，它通常可以归结为一个恶意呼叫，您可以轻松地对其进行隔离和修复。

随机工具帮助

接下来，我们分析了用于解决某些潜在根本原因的工具和技术。 我们注意到，平均而言，用户不会尝试更多，至少四个不同的工具来收集证据并找到根本原因 。 最流行的工具和技术涉及日志分析，堆/线程转储和分析器。

当我们研究工具在各种潜在问题中的使用时，我们真的感到非常惊讶。 根本的问题和用于进行故障排除的工具之间几乎没有关联-列出了相同的工具，而频率与出现的问题无关。

最好的例子可能是线程转储分析。 这是收集有关并发问题的证据的好方法。 确实，解决并发问题的受访者中有52％使用线程转储分析作为根本原因分析来源之一。 但是例如，当眼前的问题是内存泄漏时，则有42％的情况列出了相同的线程转储分析。

或者，从工具的角度来看–与问题类型无关，有41-53％的受访者使用探查器来收集证据，与症状和根本问题无关。

从这些数据得出结论是很棘手的，但是看来证据收集和分析过程是非常非正式的，并且涉及使用该特定人员以前使用或听说过的工具和技术。

结论

进行这项调查是为了指导Plumbr的进一步发展。 对我们而言，主要结论基于调查的四个关键结果：

• 查找和解决性能问题的平均时间为80小时
• 对于76％的案例，大部分时间都花在了恶性的“试图复制-收集证据-解释证据”周期中。
• 27％的情况无法复制。 在这种情况下，查找和解决问题所花费的时间增加了73％。
• 证据收集过程是完全非正式的，平均涉及四个随机选择的工具

我们承诺从这里开始，并为上述问题提供解决方案。 使用Plumbr监视系统可立即将您定位到实际的根本原因，从而完全跳过“尝试重现–收集证据–解释证据”的周期：

我们当前的产品允许线程锁定，低效率的GC和内存泄漏，但是我们一直在扩展我们的产品，因此您将拥有一个安全网来应对影响JVM的所有性能问题。

翻译自: https://www.javacodegeeks.com/2014/12/java-performance-tuning-survey-results-part-iv.html