java 性能调优






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

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

了解性能问题

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

java调查问卷调查问题如何存储 java调查报告_java调查问卷调查问题如何存储

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

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

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

性能问题的症状

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

java调查问卷调查问题如何存储 java调查报告_大数据_02

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

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

对最终用户有影响吗?

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

java调查问卷调查问题如何存储 java调查报告_java_03

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

使用的监控解决方案

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

java调查问卷调查问题如何存储 java调查报告_大数据_04

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

  1. 21%的受访者不使用任何工具 来监视生产现场
  2. 占受访者的18%
  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在此列表中的位置很可能有偏差,因此请以健康的食盐代替我们在此列表中的位置。