java 性能调优

我们在2014年10月进行了Java性能调优调查。该调查的主要目的是收集对Java性能世界的见解，以改善Plumbr产品。 但是，我们也很高兴与您分享有趣的结果。 我们收集的数据为进行冗长的分析提供了素材，因此我们决定将结果划分为一系列博客文章。 这是第一个，试图回答以下问题：

• 谁处理Java性能问题？
• Java性能问题有多广泛？
• 解决这些问题需要多长时间？
• 这个时间花在哪里？

回答我们调查的工程角色

2014年10月，共有308位受访者接听了我们的电话，并完成了调查。我们还根据其角色对受访者进行了介绍，以下图表说明了使用的不同标题：

进一步放大此分布，可以说数据是由响应者角色分配的，如下所示：

• 73％工程
• 6％的运营
• 2％质量检查
• 14％管理
• 5％无法分类

我们可以得出结论，该调查主要基于工程角色，而管理层，运营和质量保证人员则略有不同。

93％的受访者在过去一年中遇到了绩效问题

“在过去的12个月中，您是否遇到过Java性能问题？” 这是为其余调查奠定整体基础的第一个问题。 在308位受访者中，有286位（ 占93％）确认他们在去年遇到了Java性能问题 。 对于这286人，我们在调查中还有9个问题需要回答。

对于其余22位在去年没有遇到任何Java性能问题的人，这也是该调查的最后一个问题。

我们确实承认回答我们调查的人员的选择可能有偏见，并且这个数字并不真正代表Java世界的地位。 毕竟，当您构建性能监视工具时，那些经常在您的网站上闲逛的人更可能最近参与了性能监视领域。 因此，我们不能真正宣称93％的Java应用程序工作人员每年都会遇到性能问题。

我们可以肯定地说的是，我们从286个有关Java应用程序性能问题的独特示例中获得了数据。 因此，让我们看看问题到底是什么。

大部分时间都花在复制，证据收集和根本原因分析上。

在308位受访者中，有156位选择回答“过程中最耗时的部分”的问题。 这是一个自由文本问题，我们能够对146个答案进行分类。

这些答案被证明是调查中最有趣的结果之一。 令人惊讶的是，有76％的受访者在“ 试图复制-收集证据-理解证据-将证据与根本原因联系起来 ”循环中挣扎最多：

• 受访者的20％ 大部分的时间试图重现该问题，这样他们就可以开始收集证据
• 25％的人在尝试收集证据 （例如日志文件或堆/线程转储）和理解证据方面最费力
• 30％花费的大部分时间 ， 而 试图 证据源代码/配置链接到的根本原因

公平地说，您还应该注意，有相当多的受访者（13％）声称，为该问题建立实际的解决方案是该过程中最耗时的部分。 尽管这是一个可观的数额，但仍比大多数用户花费在试图找出根本原因的恶性循环中的花费少五倍多。

您花了多长时间解决性能问题？

在本节中，我们要求受访者量化他们试图发现根本原因时所面临的痛苦。 同样，我们有284位受访者回答了这个问题：

答案证实，即使某些情况很容易检测和排除故障，但大多数性能问题还是很难解决的。 荣誉给个答复谁发现，在不到一个小时的固定的问题，但让我们一会儿，专注于48名受访者停止（的情况下，17％），对他们来说，跟踪下来，并解决性能问题意味着多了一个花了一个月。

解释以上数据的另一种方法是查看花费的中位数和平均时间：

• 中位数时间落在“超过一天但不到一周”的范围内，这意味着花了几天的时间进行检测和故障排除。
• 由于缺少上界，因此平均值的计算有些棘手，但是当假设“一个多月”转化为“恰好两个月”时，用于查找和修复根本原因的平均时间为80个小时 。

如果我们看一下所花费的总时间，这些数字看起来就更令人恐惧了– 284名受访者总共花费22,600个小时来检测和解决单个性能问题。 这相当于超过130个工作月 。 仅仅考虑这个数字就清楚地表明该领域迫切需要更好的解决方案。

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

java 性能调优