这是系列文章的第二篇，我们将分析2014年10月进行的性能调整调查的结果。如果您尚未阅读第一部分，我们建议从此处开始 。 第二部分将重点监视Java应用程序的性能问题。 特别是，我们尝试回答以下问题：

• 人们如何发现性能问题？
• 这些问题的症状是什么？
• 这些问题多久影响一次最终用户？
• 哪些工具用于监视应用程序？

了解性能问题

在调查任何性能事件之前，需要知道它的存在。 我们要求描述受访者发现问题存在的渠道。 286人通过列出406个渠道进行了回复：

考虑到大多数受访者来自工程学方面 ，令我们感到非常惊讶的是，超过58％的受访者将监视软件列为意识来源。 同时， 只有38％的用户进行了负载/压力测试来提醒他们 。

这些数据正在验证我们在日常工作中看到的内容-大多数公司没有进行负载测试的可能性-创建和维护此类测试需要时间，并且经常被跳过。

归类为“其他”的11位受访者大多是指程序性活动，例如正在进行的外部绩效审核。

性能问题的症状

有了这个问题，我们希望了解问题的症状。 286位受访者列出了462个症状来回答以下问题：

到目前为止，引发进一步研究的最常见症状是过度使用资源（例如CPU，内存，IO等）。 205，占72％的受访者将其列为症状之一。 显然，监视最终用户交易的情况不那么广泛-通过更复杂的设置，仍然可以从资源端监视大多数系统，而无需考虑最终用户的交易。

另一方面，与绩效相关的问题的严重性很好地说明了这一事实，即17％的受访者仅在完全服务中断后才了解问题 。

对最终用户有影响吗？

接下来，我们了解了当前的问题是否正在影响最终用户。 284条回应给了我们以下见解：

回答“是”的82％的受访者证实了我们的直觉– 只有在相关问题开始影响最终用户时，性能才引起关注 。 业务方面倾向于将重点放在添加新功能/改进现有功能上，而使诸如性能之类的非功能需求没有引起应有的关注。 而且只有当对性能的影响如此之大以致最终用户开始抱怨时，才会分配一些资源来解决当前的问题。

使用的监控解决方案

此次调查中最有趣的见解之一就是当前的监视环境–我们要求受访者确定他们在生产现场使用的监视解决方案。 284位受访者列出了365种工具，因为一些受访者最多使用五种工具来监视其部署：

领奖台上的地方有些令人惊讶：

1. 该问题的最常见答案是“无”，这意味着21％的受访者不使用任何工具 来监视生产现场 。
2. 最常用的工具仍然是15岁的Nagios。 51人（ 占受访者的18％ ）将Nagios列为他们用于监控的工具之一。
3. 第三名被列为“ 其他 ”，由38个不同的工具组成，所有工具均得到1-2次提及。 因此，我们可以说市场上的参与者数量很大，只有一些工具设法获得了有意义的市场份额。

此列表中的下一个：在7％到13％的案例中提到了NewRelic，Zabbix，AppDynamics和Oracle Enterprise Managers。 预计NewRelic和AppDynamics具有广泛的部署基础，但是Zabbix和Oracle Enterprise Manager的部署频率肯定是出乎意料的。

还值得一提的是自建解决方案和JVM工具的数量。 自建解决方案甚至不在我们的答案列表中，因此让6％的受访者构建自己的监控解决方案有点令人惊讶。

结果的尾部包含四次或更多次提到的工具。 看到大型APM供应商（CA，Compuware和BMC）被最简单的工具Pingdom打败，这真是很奇怪。

由于该调查已列在我们的网站上，因此我们确实承认Plumbr在此列表中的位置很可能有偏见，因此以健康的食盐代替我们在此列表中的位置。

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