微信号:infoqchina

介绍:有内容的技术社区媒体

虚拟座谈会:性能调优面面观

2014-02-19 18:51 InfoQ

看上去性能调优在应用交付领域仍然没有成为主流。InfoQ采访了性能监控领域的5位大师,探讨了其原因,以及我们应该做些什么。讨论非常激烈。


本次虚拟座谈会邀请到了如下几位成员:


Ben Evans是jClarity的CEO。jClarity是一家创业公司,主要交付辅助开发和运维团队改进性能的工具。Evans是Oracle的Java Champion荣誉得主,还是一位畅销书作家。

Charlie Hunt是Salesforce.com的性能工程架构师(Architect of Performance Engineering),也是畅销书“Java Performance”的第一作者。这本书的中文版《Java性能优化权威指南》也即将出版了,感兴趣的读者可以关注一下。

Kirk Pepperdine是世界著名的性能调优顾问、培训师,Oracle的Java Champion荣誉得主,《程序员应该知道的97件事》一书的贡献作者之一。

Martin Thompson是高性能和低延迟方面的专家,在大规模事务和大数据系统方面有20多年的工作经验。

Monica Beckwith在Oracle负责领导G1垃圾收集器的性能相关工作。


InfoQ:多数组织往往忽视性能调优与测试。至于如何克服这些困难,或许你们可以分享一下自己的经验。要使性能调优成为主流,公司可以应用哪些实践、工具和资源呢?


Martin:“往往忽视”这种说法太保守了!看上去大部分团队就是把产品赶出来,根本不考虑质量或诸如性能、可用性和安全等任何非功能性需求。


InfoQ:的确。最有说服力的是,我们最近面试过一些候选人,他们应聘的都是相当高级的Java职位,这些有经验的开发者之中,从来没用过分析器(profiler)、对性能调优和垃圾收集一无所知的,多得让我难以置信。这种情况是由调优内在的困难导致的吗?还是说性能只是被当做事后才考虑的东西了?公司应该如何纠正这种问题?


Martin:回忆我的咨询工作,人们对性能测试和调优的了解之少,是真正让我惊讶的。即便性能是他们领域的一大关键需求,结果也是如此。


Ben:你提到的问题,有些是有联系的,而且与我们如何培养性能工程师有关。最近经常看到这种说法:“培训是教人高效可靠地执行某项具体任务,另一方面,教育是开启人的心智并充实其思想。”我认为相当中肯。


在处理性能问题时,培训和教育两个方面都是必要的。我们需要让学生对实验数据、统计值和可重复运行等几点在性能分析和调优中的重要性有个印象,这主要是培训方面的问题。然而,我们也需要让他们理解,如何把自己在整个应用栈上的经验应用于解决性能问题,而这更多是教育方面的问题。


不仅如此,我们还需要引导他们避免以“要诀与技巧(tips and tricks)”的方式来处理性能问题。这种方式教起来容易,因为它本质上一种培训技术,而非教育。


最后,在应对教育或培训时,学生们必须定期使用新的材料与技巧,否则他们就会再次止步不前。如果性能课程不能作为持续12个月的核心课程的一部分,那基本没什么用。


Kirk:不久之前我看了Eric Smart关于性能的一次演讲。他指出了他们所遇到的所有典型错误。首先,主要关注点是特性、特性以及更多的特性。他们本以为,大家都很聪明,当需要性能时,就能把性能搞出来。麻烦的是,当最后需要解决性能问题时,情况变成了这样:每天都是几乎要实现了,再有一点点时间就行,再有一天就行,再有一周就行,再有一个月、两个月、三个月,然后是四个月……。那时他们就停了下来,然后思考“这是怎么回事”。他们意识到,因为没有将性能作为日常工作的一部分,他们忽略了在小范围内无法发现的问题。正是要处理的这些问题,几乎搞砸了整个项目,甚至进而把公司给搞垮了。


好在最后结果还不错,因为他们能把缓缓走向失败的项目转危为安。但是顿悟之后,他们才意识到传统的开发环节已经无法很好地满足需求。


Monica:还有一方面,在有些公司中,所谓“性能工程师”,几乎就是负责收集一些数据(原始数据、日志或分析文件)比较一下,但却因为缺乏知识或缺乏组织承诺(Organization Level Commitment),不能对数据进行分析和深层挖掘,进而无法发现隐蔽的性能问题。另一方面在于性能工程师,因为他可能工作在不同的组中,所以对产品没有直接的贡献。而且性能工程师所提议的重大变更,对组织投入资源而言可能太过昂贵。我认为这种情况下的问题可以归咎于对全面的性能规划(Performance Planning)缺乏理解或缺乏清晰的定义。


前面已经说过,在我的职业生涯中,我已经注意到了组织承诺,但我认为很多公司必须解决不同组的隔离问题,而且一些“性能工程师”也必须加强自己的知识储备。即便如此,我还是和很多对性能很有经验的开发者一起工作过。对一个公司而言,有这样的开发者就像中了头彩。


性能调优是一门艺术。有些从业者可能就是比其他人更有天赋,但是无论谁肩负起这个角色,都必须实践和完善这门艺术。性能工程师责无旁贷,要将知识传授给其他人。通过开发的论坛和会议,通过向团队咨询,这是很容易实现的。


Kirk:我认为这完全取决于你对“调优”的理解。尝试找出性能为何未达预期,是个诊断问题。在将状况诊断清楚之后,知道该做什么,又会分为两类:


  • 我们之前曾经见过该问题,解决方案也很好理解

  • 我们需要想出新方法,以便进一步挖掘硬件的潜力

所以解决方案不仅依赖诊断能力,还依赖做什么才能改进性能。但根据我的经验,大部分性能问题,只要能检测到,解决是非常容易的,所以我认为最大的困难还是在诊断上。


“有多少人被教过如何使用分析器?”在Devoxx London会议上,我第一次听到Martin提这个问题。我的第一个念头是,这真是个简单却又明智的问题。我从来没想过要问这个问题,因为我知道答案。但这个问题仍然需要明确地提出来。在诊断中,分析器是一个重要的工具,但我还没听说哪所学校或哪个机构涉及到了这一主题。有些有志探索调优这一主题应如何教学的教授曾联系过我,但是没有下文了。


回到调优很难这一看法,我认为原因之一在于调优是一种诊断活动,本质上不同于开发。就其性质而言,调优需要调查,需要获得测量数据。不仅是测量,还要是正确的测量,问题又暴露出来了。这正是问题所在:如果大家都知道测量就是在IDE中运行分析器,那正确的测量又该如何得到呢?没有正确的测量,又得依靠直觉或猜想了。依靠直觉的问题是,我们不太可能想清楚软件最终满足硬件和真实用户的需求时,其间的所有交互。意识到这一点,我和Jack Shirazi在很多年前就杜撰了“测量,别猜”(Measure, Don't Guess™)这一说法。这也是我在课程中讲述性能诊断模型(Performance Diagnostic Model™,简称PDM)的因由。经由PDM,我们帮助开发者重新组织了他们已经掌握的知识,使他们能够借此缓解诊断性能问题时遇到的困难。


尽管PDM有所帮助,但是它只是轻微地改进了我们的示例练习的成功率。这是因为,诊断尚需要另外一种技能,那就是思维跳出细节、理解整体目标的能力。诊断和其他任何故障定位形式类似,需要深挖细节,有时这会使改变重点以获得更广泛地理解有些困难。我也不知道如何克服。不过这个问题确实会影响人们跟踪诊断过程的能力。


Martin:我们观察到,大部分人不进行测量,或者不使用分析器。不过我还发现一个更有意思的现象。有的团队,既进行了分析,也收集了系统指标,但是当面对收集到的数据时,好像这一切都没什么意义。我经常走到客户中间,他们告诉我遇到了性能问题。我就会问,你们是否以不同方式对应用进行了分析?他们往往都购买了分析器许可,打开了GC日志,sar(System Activity Report)也用上了,等等。当他们给我看数据时,我非常吃惊。答案就在眼前,但是看上去他们却发现不了。我花了一段时间才意识到,不是说他们不够聪明,他们只是不知道如何诠释这些数据,因为他们还没有磨练出这种技巧。就和我们使用调试器一样,如果工作中天天用,它就变成第二天性了。如若不然,它几乎总是我们的障碍。


Charlie:Monica所言极是,公司不同,谈话的对象不同,看上去“性能工程师”的定义也会有所不同。在有些公司,性能工程师负责性能测试,负责针对开发中的产品运行性能负载并报告负载执行结果这样的质量工作;说明性能是改进了,衰退了,还是并不确定。而在其他公司,性能工程师的工作就更进一步,他们要分析并找到性能改进或衰退的源头。还有一类性能工程师,不仅要分析,还要寻找优化的机会。我们看到了一系列角色、职责和所需的技能。我猜测参加这次座谈会的每一位都属于最后一类。我认为每个应用开发者都应该对其所开发应用的性能很感兴趣,而不只是把“性能(或质量)”看做别人的活。我曾听到一位开发工程师这么说:“测试我的代码不是我的活,要不还要质量和性能工程团队干嘛。”恕我直言,这种工程师应该立马开除!


Martin:将性能工程师从“普通工程师”中划分出来,实际上是一种大大的反模式。我完全认同的是,功能性需求和非功能性需求的质量是所有工程师/程序员的责任。但是看看这个例子。在一次面试中,我曾问到:HashMap和TreeMap有什么区别?如果他告诉我,HashMap的时间复杂度是O(n),而TreeMap的时间复杂度是O(log n),我会很满意。如果他能解释一下它们的实现,我会非常高兴。但他的回答是,“程序员再也不需要知道这类知识了”,让我很不舒服。的确,团队里有专家是好事,但是这些专家需要指导团队的其他人员,从而提高整个团队的水准。


Charlie:我认为困难不仅在于调优,还在于分析和找出优化的机会。离开性能工程“科学”的一面,接触其“艺术”的一面,事情又困难了。我会以类似方式描述统计学这一学科。统计学和统计方法有“科学”的一面,而应用恰当的统计方法也有“艺术”的一面。科学的一面,像统计学、各种不同类型的计算公式等,你可以讲授给大家;但是艺术的一面,比如在既定情境下使用恰当的统计方法,讲授起来就完全不同了。类似,我们可以把性能工程科学的一面讲授给大家,但艺术的一面也是完全不同的。我认为真正受困于性能工程的人其实是受困于其艺术的一面,遗憾的是,这正是不容易讲授或学习的。


Kirk:我可能不太同意你的定义。提到艺术,我想到的是无法测量或不能很容易地量化的东西。而性能是可以测量、可以量化的。在我的世界中,如果你说“艺术”,我会理解为“我只是猜测”。有些人可能比其他人更擅长猜测,但根据我的经验,这并不是因为他们能够凭空发现答案;相反,他们的心智模型相当发达,可以将可用的数据放入大脑,然后得出一个质量较高的答案。在我的课程中,我看到过这种情况。我提了一个带有少量数据的问题,开发者们苦思冥想。然而在给他们提供了一个可以利用的心智模型之后,突然之间,问题的答案就从少量的这些数据中蹦了出来。线索就在身边,我们需要的只是认出它们。我认为这不是艺术,因为这里是要理解测量值表示什么。以创新的方法从我们目前不得不使用的硬件中挖掘出更多东西,那才是“艺术”。


Charlie:我所谓的艺术并不是指“猜测”。在性能工程的艺术中,一种形式是模式匹配。你用你在课程中所做的事情来描述的东西,正是试图提供性能工程科学的一面,同时把艺术的一面传授给同学们。知道测量或监控什么,知道某个指标的阈值,是进行进一步调研的依据。知道使用什么工具,并且能利用相关知识定位到问题根源,就是我所指的艺术。也就是知道如何将正确的性能工程方法学应用于恰当的情况。如果它是科学,它就应该可以用数学的方式建立模型。你用以描述它的“心智模型”,就是我所谓的“艺术”。知道猜测或推测什么,缩小要猜测的东西的可能范围,或是以充分了解、受过培训的方式猜测,再或是知道需要哪些额外的数据来帮助做出明智的决定,这种种方面,都在我所谓的“性能工程之艺术”的范畴中。


Kirk:是的,我发现还有一个坏习惯,人们经常从数据中推导出一些并非必然的结论。他们只是假设或推测,或是像我的书里说的那样,就是猜!我可以举个例子。在堆图中,在一次垃圾收集之后,向上的曲线意味着内存泄露,是这样吗?我说这是一个基于推测的过度化结论。我可以把能证明你的错误的GC日志发给你。我是如何知道其中的区别的呢?这不是艺术,我只是问了一下其背后的目的。这一切都有算法可循吧?我想是的。


Charlie:或许我们应该考虑一个问题:为什么在给软件工程的学生开数学和计算理论课程之前,大部分学校都会先教学生一门编程语言?对比一下,其他工程学科,比如机械工程或工业工程,则会先教给学生数学和本学科的理论。


几位专家还探讨了公司应该将资源投入哪些工具和技术。更多精彩内容,请点击阅读原文。


***********************************

本文来自InfoQ微信公众账号:infoqchina

1、回复“今日新闻”,查看今天更新的新闻;

2、回复“今日英文”,查看今天英文站的更新;

3、回复“文章 +关键词”,搜索关键词相关内容;

4、回复“QCon”,了解QCon大会相关信息;

5、回复“活动”,了解最近InfoQ组织的线下沙龙;

6、回复“架构师”,获取《架构师》下载地址;

7、回复“投稿”,了解投稿和加入编辑团队的流程。

***********************************

 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 高德LBS硬件编程马拉松 团队火热招募中 极女神出场城隍庙七夕派对,盆满钵满归来 2013年IBM闪存系统的营收全球第一 程序员真的很懒 世界OL转型HTML5,重度手游的积极探索