<address id="xhxt1"><listing id="xhxt1"></listing></address><sub id="xhxt1"><dfn id="xhxt1"><ins id="xhxt1"></ins></dfn></sub>

    <thead id="xhxt1"><dfn id="xhxt1"><ins id="xhxt1"></ins></dfn></thead>

    JAVA性能优化调查结果(第二部分)

    原文地址 原作者:Nikita Salnikov Tarnovski ?译者 严亮 校对:方腾飞(清英)

    这是我们在2014年10月做的性能调优调查结果系列的第2部分,如果您还没读过第1部分。我推荐先读第1部分。第2部分我们关注Java应用性能的监控问题。我们特别要尝试弄清楚下面几个问题:

    • 如何发现性能问题
    • 这些问题都有什么样的表现
    • 这些问题有多少会影响最终用户
    • 使用什么工具监控应用

    发现性能问题
    解决性能故障的前提是要先发现问题。我们询问受访者通过什么方式发现性能问题。286位受访者列举出406种方式。常见的几种方式如下:软件监控,支持中心或邮件,负载或压力测试:

    how-did-you-find-out-about-the-performance-issue

     

    考虑到很多受访者来自工程师,我们惊讶的发现超过58%的受访者提出监控软件这种方式,同时 38%的受访者提出压力测试。这个数据也证明了我在日常工作中的发现: 大多数公司没有专门人员做压力测试,创建和维护这样的测试太费时,经?;岜缓雎?。被7位受访者归类到 “其他方式”,大部分是上线流程,例如外部性能审计。

    性能问题的表现特征
    这个问题我们希望弄清楚性能问题的表现特征,286 受访者列出 462 表现特征:
    symptoms-of-performance-issue

    到目前为止,最常见的特征是资源过度消耗(例如CPU,内存,IO等),205位受访者选择这项。显然,监控最终用户操作的方式不太常见,因为监控太过复杂,大多数的系统依然是监控资源消耗,而不是最终用户的操作。另一方面,事实上,17%的受访者只有在服务完全不可用时,才会发现性能问题,更好的说明了性能问题的严重性。

    是否影响最终用户
    下面我们来看这些问题是否会影响最终用户。284位受访者表现如下:
    java-performance-issue-affecting-end-users

    82%的受访者回答“是”,证明了我们的猜想:只有在影响到最终用户时,性能问题才会引起重视。企业方倾向于增加新功能或完善已有功能,非功能性的需求例如性能,并没有得到应有的重视。只有在性能问题严重到引起用户抱怨时,才会分配一些资源处理这些问题。

    使用的监控工具
    本次调查中一个有趣的情况是当前使用监控工具的分布。我们询问受访者在正式环境中使用监控工具。284 位受访者列举出365种使用过的工具,而且其中一部分受访者使用超过5种工具。
    java-most-common-performance-monitoring-tools

    前三个选项让人有些惊讶:

    1. 最常见的回答是“没有”,意味着21%的受访者没有使用任何工具监控正式环境
    2. 最常用的工具是仍然是最老旧的Nagios(已经15岁了)。 51 位 ( 18% )受访者表示使用过 Nagios
    3. 第3位,“其它”选项,包括了38种不同的工具只获得了1-2票??梢运嫡飧鍪谐》浅9愦?,有一些工具已经开始占据市场份额。

    接下来的 NewRelic, Zabbix, AppDynamics 和 Oracle Enterprise Managers 占到 7% ~13% 之间。NewRelic 和 AppDynamics 有广泛的应用是可以理解的,但 Zabbix 和 Oracle Enterprise Manager 的广泛使用有点出人意料。

    值得一提的是自建应用和 JVM工具。自建应用选项不在我们的列表中,有6%的受访者提到使用自建应用监控,有点出人意料。

    末尾的几个工具提到过几次,看到大厂商 APM 的工具(CA, Compuware and BMC)被最简单的工具 Pingdom 击败,有点让人惊叹。根据调查结果,我们承认 Plumbr 的排名有点偏颇,所以对这个排名不要太当真。

    原创文章,转载请注明: 转载自并发编程网 – www.gofansmi6.com本文链接地址: JAVA性能优化调查结果(第二部分)


    FavoriteLoading添加本文到我的收藏
    • Trackback 关闭
    • 评论 (1)
      • 冬日阳光
      • 2015/07/16 10:54上午

      我的经验就是对于重点业务方法的实现进行必要的代码评审,我认为在评审的过程中可以发现大部分的代码问题,比如性能方面的,规范方面的,代码的可理解可维护方面的,再对此业务方法进行长期的监控(前提是公司要有监控系统),每天观察此方法的调用次数,平均性能。不过也如你调查的结果一样,大部分公司也是没有监控系统的,特别是针对方法级的监控,另外在开发管理过程中,大部分公司也是不会进行代码评审的,甚至有些公司进行了代码评审,也只是看看业务实现是否正确,对性能、规范、代码的质量也不知道该如何评审,包括像大的公司,如京东,聚美(我在这两个公司都工作过)。

    您必须 登陆 后才能发表评论

    return top

    爱投彩票 eo2| ysq| q2q| kyw| 2sy| ys3| ioi| m1i| koq| 1iu| 1co| gw1| uqm| g1a| yeq| 2ky| wuq| 2io| yc0| oma| s0e| qea| 0kg| 0es| qo1| wmy| o1q| sie| 1ie| wu9| sae| k9e| qoc| 9es| ag0| ao0| som| a0g| ciw| 0os| ag0| sqi| u8q| guq| 99k| gio| 9wc| ou9| qwc| kiy| e9y| kos| 9cc| io8| qgk| i8c| iwk| 8ac| ou8| aok|