开源虚拟主机控制面板
在应用程序交付的世界中，性能调整似乎仍未成为主流。 InfoQ采访了性能监控领域的五位专家，说明了为什么以及可以做什么。 结果是一个非常活跃的辩论。
虚拟小组成员：
Ben Evans是jClarity的首席执行官，该公司是一家提供性能工具以帮助开发和运营团队的初创公司。 他还是Oracle Java冠军和畅销书作家。
查理·亨特 （ Charlie Hunt）是Salesforce.com的性能工程架构师，也是最畅销的书籍“ Java Performance”的主要作者。
柯克·佩珀丁 （ Kirk Pepperdine）是举世闻名的性能调优顾问，培训师，Oracle Java Champion，并且是《每个程序员都应该知道的97件事》一书的特约作者。
Martin Thompson是一名高性能和低延迟专家，在大型事务和大数据系统上有超过二十年的工作经验。
莫妮卡·贝克维斯 （ Monica Beckwith）是垃圾第一垃圾收集器的Oracle性能主管。
InfoQ：大多数组织倾向于忽略性能调整和测试。 也许您可以分享有关如何克服这些困难的经验。 公司应采用哪些实践，工具和资源将性能调优纳入主流？
马丁 ：现在“轻描淡写”实在是轻描淡写！ 大多数似乎只是急于将产品淘汰，根本不考虑质量或诸如性能，可用性，安全性等任何非功能性要求。
InfoQ：我同意； 最能说明问题的是，我最近一直在采访一些Java相当资深的工作的候选人，令我感到不可思议的是，有多少有经验的开发人员从未使用过探查器，而对性能调优或GC一无所知。 这是固有困难的结果吗？ 还是只是将性能视为事后才考虑？ 企业可以采取什么措施来纠正这一问题？
马丁（Martin） ：现在，回到咨询领域，真正令我感到惊讶的是，即使性能*是其领域的关键要求，很少有人对性能测试和调整有所了解。
本 ：我认为您提到的一些问题是相关的，并且与我们如何发展绩效工程师有关。 我最近看到了这句话，我认为这是相关的：
“培训教会人们如何更有效，更可靠地执行特定任务。另一方面，教育可以打开并丰富人们的思想。”
处理性能问题时，这两个方面都是必需的。 我们需要在表现分析和调优（这是培训方面）上向学生强调经验数据，统计数据和可重复运行的重要性。 但是，我们还需要他们了解如何将自己的经验应用于整个应用程序堆栈来解决性能问题（这更多是教育方面的问题）。
不仅如此，我们还需要引导他们摆脱“技巧”的表现（这更容易教授，因为它本质上是一种培训技术，而不是教育）。
最后，在进行教育或培训时，学生必须定期使用材料和新技能。 否则它们将再次萎缩。 进行为期12个月没有被用作核心职责的绩效课程基本上是没有用的。
柯克 ：前一段时间，我看到了埃里克·斯玛特（Eric Smart）的表演演讲。 他在讲话中指出了他们犯下的所有经典错误。 首先，重点是功能，功能以及更多功能。 他们是一群聪明的人，当需要整理时，性能会自行整理。 麻烦的是，当最终需要对性能进行整理时，它变成了一种练习，每天他们几乎都在那儿，只需要一点点时间，我们就可以完成一天，一天，一周，然后一个月，两个，三，然后四。 那时他们休息一下，问“好吧，这是怎么回事？” 他们意识到，不将性能作为日常工作的一部分，他们就忽略了小型设备中看不到的问题。 他们正在解决的正是这些问题，以至于该项目几乎失败了，并最终使公司失败。
这个故事有一个圆满的结局，因为他们能够将缓慢的失败转化为成功。 但是，突然发现，传统的发展道路并不能很好地为他们服务。
莫妮卡（Monica） ：在另一方面，公司聘请了一个名为“绩效工程师”的人，他们几乎收集数据（原始，日志或配置文件）进行比较，但是却不能花费大量的时间（由于缺乏知识或缺乏组织级别的承诺）对数据进行分析和“深入研究”以发现任何秘密的绩效问题。 另一端是绩效工程师，因为他或她在一个独立的团队中工作，所以不直接对产品进行投资，并且总是建议进行重大更改，而这些更改可能对于组织投资资源而言过于昂贵。 我认为在这种情况下，问题可能归结为对全面的绩效计划缺乏理解或明确定义。
话虽如此，我在整个职业生涯中都恪守组织层面的承诺，但是我认为相当多的组织必须致力于解决团队间的联系，而一些“绩效工程师”还必须致力于建立自己的知识。 也就是说，我还与许多精通性能的开发人员一起工作。 这就好比为一个组织赢得大奖。
性能调整是一门艺术。 有些从业者可能比其他从业者更有才华，但无论是谁承担的角色，都必须实践和完善这种艺术。 然后，我们的性能工程师必须将我们的知识传授给其他人。 这可以通过公开的论坛和会议以及直接与团队协商来轻松实现。
柯克 ：我想这一切都取决于您调整的意思。 试图弄清为什么应用程序未达到预期效果是一个诊断问题。 一旦诊断出状况，知道如何处理可能会落在两个方面：
我们之前已经看过了，解决方案已广为人知
我们需要想出一种新颖的方法来充分利用硬件。
因此，解决方案不仅取决于诊断能力，还取决于需要采取哪些措施来提高性能。 但是根据我的经验，一旦发现大多数性能问题就可以轻松解决，因此我认为最大的困难是诊断。
当我第一次听到马丁在Devoxx伦敦问“是否教过多少人如何使用探查器”问题时，我的第一个想法是“这是一个简单而又精妙的问题！” 我从来没有想过要问这个问题，因为我知道答案。 但是仍然需要指出这一点。 这应该是我们诊断工具库中的重要工具，但我不知道涵盖该主题的一所学校或其他机构。 有几所大学的教授与我联系，他们有兴趣探讨如何教授调音课程，但从来没有真正超越过。
回到难以调整的想法，我认为原因之一是它是一种诊断活动，因此与开发根本不同。 就其性质而言，它是一种调查，而就其性质而言，它要求人们进行测量。 不仅要进行任何测量，还要进行正确的测量，这是暴露问题的一种方法。 其中存在一个问题：如果一个人都知道如何使用它，那么应该如何进行正确的测量，那就是在IDE中运行的执行事件探查器。 但是，如果没有正确的度量方法，您将只能凭直觉进行其他猜测。 直觉的问题是，人们无法想象当软件最终遇到硬件和真实用户时发生的所有交互。 这种认识导致了杰克·西拉齐（Jack Shirazi）和我几年前提出的“测量，不要猜测”的口头禅。 这也导致我们在课程中教授我的Performance Diagnostic Model™。 PDM帮助我帮助开发人员将他们已经知道的内容重新打包为可以缓解诊断性能问题的麻烦的东西。
尽管PDM有所帮助，但通过我的示例练习，它仅成功地提高了成功率。 这是因为诊断还需要另一项技能，那就是能够使您的思维脱离细节而理解整体目的。 诊断像任何形式的故障排除一样，都需要您深入研究细节，有时难以重新定位以便获得更广泛的了解。 解决这个问题的方法超出了我的薪水等级。 但这肯定会影响人们遵循诊断过程的能力。
马丁（Martin） ：我们观察到“大多数不测量或不使用轮廓仪”。 但是我观察到了一个更有趣的现象。 对于进行概要分析并收集系统指标的团队来说，当他们查看数据时，似乎对他们没有任何意义。 我经常去找客户，他们告诉我他们有一个性能问题。 我问他们是否以各种方式对应用程序进行了概要分析。 在我的空间里，他们经常有探查器许可证，GC日志记录打开， 系统活动报告等。然后，当我向我展示数据时，我感到很惊讶。 答案就跳到我身上，他们似乎看不到它。 我花了一段时间才意识到这不是因为他们不聪明。 他们只是不知道如何解释数据，因为他们没有磨练这项技能。 这类似于我们使用调试器发现的内容。 当您的工作习惯每天都在执行时，它就变成了第二天性。 除非这几乎是一个障碍。
查理（Charlie） ：我同意莫妮卡（Monica）的定义，“绩效工程师”的定义似乎因公司和与您交谈的人而异。 在某些公司中，性能工程师是执行性能测试的人员，质量类型功能是他或她针对正在开发的产品运行性能工作负载并报告工作负载执行结果的人员。 改进，回归或无定论。 在其他情况下，性能工程师会采取下一步措施，并进行一些分析，以确定改进或回归的来源。 而且，还有另一种类型的性能工程师，他们不仅进行分析，而且还在寻找优化机会。 因此，我们观察到所需的各种角色，职责和技能。 我怀疑此小组中的每个人都属于后一类，并且我还相信正在开发应用程序的任何人都应该对他或她正在开发的产品的性能感兴趣，而不仅仅是将“性能”（或质量）视为别人的工作。 我曾经听过一位开发工程师说：“测试代码不是我的工作。这就是我们拥有一支质量和性能工程团队的原因。” 以我的拙见，那个工程师应该当场被解雇！
马丁 ：将性能工程师与“常规工程师”分开是一个巨大的反模式。 它由于多种原因而失败。 我完全同意功能和非功能需求的质量是所有工程师/程序员的责任。 但是考虑一下：在一次采访中我曾问过：“ HashMap和TreeMap有什么区别？” 如果他告诉我HashMap为O（n）而TreeMap为O（log n），我会很高兴。 如果他甚至解释了实现方式，我会很兴奋。 但是当他说“程序员不再需要那种东西了！”时，他的React让他很不高兴。 是的，拥有专家很棒，但是他们需要指导团队的其他成员来提出标准。
查理（Charlie） ：我认为困难不仅限于调整，分析和确定优化机会。 当您开始将性能工程的“科学”留给性能工程的“艺术”时，事情就变得困难了。 我会以类似的方式描述统计学的学科。 统计和统计方法都有“科学”，应用适当的统计方法也有“艺术”。 您可以教人们统计科学，各种不同类型的计算公式，但教给人们在特定情况下使用适当的统计方法进行使用的技巧是完全不同的。 以类似的方式，我们可以教人们性能工程学。 但是性能工程的艺术是完全不同的。 我认为那些真正在性能工程方面苦苦挣扎的人正在与性能工程的技术作斗争，但是不幸的是，这并不是一件容易的事情。
柯克 ：根据您的定义，我可能不同意。 当我想到艺术时，我想到的是无法衡量或难以量化的事物。 当我想到性能时，我想到的是可以衡量并且可以量化的东西。 在我的世界里，如果您说“艺术”，您真正的意思是“我在猜测”。 有些人可能比其他人更擅长猜测，但根据我的经验，这并不是因为他们能够凭空判断出答案。 而是他们拥有完善的思维模型，可以在其中插入可用数据并获得更高质量的答案。 我在课程中看到了这一点，在这里我提出了一个数据量最少的问题，并且看着开发人员在努力。 然而，在为他们提供了一种可以突然使用的思维模型之后，这些最小的数据量却激起了问题的答案。 线索无处不在。 我们只需要能够识别它们即可。 我不认为这是艺术。 这是关于了解度量表示的内容。 “艺术”正在提出新颖的方法，以从我们当前必须使用的硬件中获得更多收益。
查理 ：当我说艺术时，我并不是要猜测。 性能工程中的一种艺术形式是模式匹配。 您在课程中所做的描述是在尝试提供性能工程学，然后教授性能工程学。 知道要测量/监视的内容，知道指标的阈值的行为值得进一步研究。 知道使用什么工具并将其吸收到根本原因是我所说的艺术 。 它知道如何在正确的情况下应用正确的性能工程方法。 如果这是科学，则可以进行数学建模。 正如您所描述的，“心理模型”就是我所说的“艺术”。 知道猜测或推测的内容，缩小猜测的可能性或进行有根据的有根据的猜测的方面，或者知道做出明智的决定所需的其他数据属于我所谓的绩效艺术工程。
柯克 ：是的，我发现另一个坏习惯是人们经常得出不一定从数据中得出结论的结论。 他们在猜测或推测，或者在我的书中只是猜测！ 我可以举一个例子。 在垃圾回收之后，堆图中的向上倾斜曲线意味着内存泄漏，对吗？ 我说这是基于推测的过度结论。 我可以将错误的地方发送给您的GC日志。 我怎么知道区别，这不是艺术，我只是问意图。 所有这些都是算法的吗？ 是的，我相信是的。
查理（Charlie） ：也许要考虑的一个问题是：为什么大多数大学在向软件工程专业的学生教授数学和计算理论之前就向他们教授编程语言？ 与其他工程学科（例如机械工程或工业工程）相反，在这些学科中，首先向学生教授其学科的数学和理论。
柯克 ：我不想低估统计数据的重要性，但是通常，通过排队论可以更好地描述计算机系统中发生的事情。 据我所知，很少有软件开发人员或测试人员对排队理论非常了解。 我认为您不需要对该主题有深入的了解，但是有必要有所了解并知道如何应用它。
查理（Charlie） ：我一直将排队论视为统计研究/学科的一部分。 我第一次接触排队论是在统计学课程中。 请记住，您使用排队论建模的大部分内容都是基于概率密度函数，即泊松，指数分布和其他分布。
马丁（Martin） ：虽然我在很大程度上同意查理（Charlie）和他那三腿的性能折衷，但是我发现这在某些情况下是有害的。 在考虑运行时和GC时，是的，它适用得很好。 但是考虑数据结构时，占用空间小通常意味着低延迟和高吞吐量。 为了提供一些背景信息，我研究了吸收整个北美金融市场供稿的系统，该系统可以维持每秒超过1100万条消息的周期。 考虑到现代x86服务器的体系结构，我们仅对L1缓存上的大页面（2MB）具有TLB缓存支持。 L2缓存仅具有用于4K页的TLB缓存。 英特尔即将发布的Haswell芯片将于明年面向服务器推出时，将在L2缓存中支持2MB页面。 当其余代码有效时，这可能成为主要问题。 由于预取器的原因，我们没有注意到扫描GC卡表的情况，但是对于大多数其他数据结构而言，这是一个主要问题。 我想我说的是主流的良好通用规则，但在更高端，其他事情可能变得更加重要。
InfoQ：组织应投资哪些工具和技术以将绩效分析纳入主流？
莫妮卡 ：首先，正如我提到的，是绩效计划。 二是建立绩效基础设施。 性能测试应该是产品生命周期的一部分。 因此，必须投资于强大的性能基础架构。 许多组织会因为没有领先于游戏而陷入困境，在知道之前，他们需要投资更多的资源来“修补问题”。 对于组织或其员工而言，此行为是不健康的，非生产性的并且资源效率不高。
查理 ：最近我一直在考虑这个问题。 你们中的一些人可能听说过我在吞吐量，延迟和占用空间方面谈论性能。 当谈到满足应用程序的性能目标时，我已经开始向产品团队和赞助执行人员提出八个问题：
预期吞吐量是多少？
您可以承受的最低吞吐量是多少（不低于此值）？吞吐量下降到该级别的频率如何？持续多长时间？
什么是吞吐量指标，如何衡量？
预期的延迟时间是多少？我们可以多久才能超过该值？持续多长时间？
您永远无法超越的延迟时间是多少？
什么是延迟指标，如何衡量？
可以使用的最大内存量是多少？
如何测量内存使用情况？
我注意到有些公司和组织未能适当地获取适当的指标。 这是我最近看到的一个示例（顺便说一下，不是在Salesforce上 ）。 假设您有兴趣减少内存占用。 但是性能标准不仅是减少内存占用，还不需要增加CPU利用率，不减少吞吐量和不减少响应时间。 如果真是这样，那么实际上是您正在尝试实现内存占用量的减少，但不愿意牺牲吞吐量或延迟方面的任何东西。 祝一切顺利！ 要强调这些属性之一的改进，在此示例中，在保持吞吐量和等待时间不变的同时，内存占用量将需要大量/不小的开发工作。 您很少会在不牺牲其中一个或两个其他属性的情况下实现其中一个性能属性的改进。 令我惊讶的是，很少有人能理解这种关系。
一个类似的问题是如何对应用程序进行测试？ 您如何捕获预期和计划的生产用途？ 我认为您必须了解并描述应用程序的最坏情况下的性能行为，尤其是当您要构建的平台是供其他人在其之上构建应用程序的平台时。 此外，您还需要捕获应用程序的预期和预期生产使用情况的性能。 您还需要关闭作为工作负载开发的内容与应用程序在生产中的性能之间的循环。 换句话说，根据这三个性能属性，工作负载在预测生产性能方面的效果如何？ 我很少观察到有人关闭这个循环并衡量其工作负载的有效性。
柯克 ：很棒的清单。..我要补充一点，我们处于一个遭受“ CPU羡慕”之苦的行业，而CPU常常不是问题所在。 因此，了解我们正在使用的硬件的基本限制并将其与我们实际需要的资源相关联是一个巨大的问题，很少有人能够解决。
我认为我们将看到越来越多的性能问题，而不仅仅是与CPU有关。 如果我们还没有经历或观察过它，我想我们可以预期会出现诸如内存总线容量之类的问题，或更普遍地说，我们可以从内存中将数据获取到CPU缓存的速度。 内存是新磁盘。 每个CPU插槽具有大量硬件线程的一大挑战是拥有足够的内存总线容量以及足够的CPU缓存。 两年前，我已经观察到一个多核系统，在达到任何接近峰值CPU使用率之前，它都会使内存总线容量达到饱和。 今天有多少人会知道如何测量内存总线容量，甚至想到测量内存总线容量？
我可以告诉您最后一个问题的答案，因为我一直都在问那个……没人！ 但是，几年来，我一直在遇到受该资源约束的应用程序。
马丁（Martin）：我们已经达到了行业朝一个方向过度发展的地步。 我们正确地一直在努力提高开发人员的生产力和交付的可预测性，但这付出了代价。 现在，我们生产的软件效率很低，以至于我无法想到可以容忍这些低效率水平的任何其他行业。 通过采用更简洁的设计和一些由性能分析驱动的调整，我们的许多软件可以将吞吐量提高10到100倍，或将延迟降低。 在某些情况下，我已经看到1000倍的改进。 我们的数据中心成本现在变得越来越高，而二氧化碳排放量的2-4％现在与计算有关。 我们还必须考虑移动设备的爆炸式增长，在这些设备上高效的软件可以直接转化为节电，并且减少了提供主要基于服务器计算的移动服务的服务器。
开源虚拟主机控制面板
在应用程序交付的世界中，性能调整似乎仍未成为主流。 InfoQ采访了性能监控领域的五位专家，说明了为什么以及可以做什么。 结果是一个非常活跃的辩论。
虚拟小组成员：
Ben Evans是jClarity的首席执行官，该公司是一家提供性能工具以帮助开发和运营团队的初创公司。 他还是Oracle Java冠军和畅销书作家。
查理·亨特 （ Charlie Hunt）是Salesforce.com的性能工程架构师，也是最畅销的书籍“ Java Performance”的主要作者。
柯克·佩珀丁 （ Kirk Pepperdine）是举世闻名的性能调优顾问，培训师，Oracle Java Champion，并且是《每个程序员都应该知道的97件事》一书的特约作者。
Martin Thompson是一名高性能和低延迟专家，在大型事务和大数据系统上有超过二十年的工作经验。
莫妮卡·贝克维斯 （ Monica Beckwith）是垃圾第一垃圾收集器的Oracle性能主管。
InfoQ：大多数组织倾向于忽略性能调整和测试。 也许您可以分享有关如何克服这些困难的经验。 公司应采用哪些实践，工具和资源将性能调优纳入主流？
马丁 ：现在“轻描淡写”实在是轻描淡写！ 大多数似乎只是急于将产品淘汰，根本不考虑质量或诸如性能，可用性，安全性等任何非功能性要求。
InfoQ：我同意； 最能说明问题的是，我最近一直在采访一些Java相当资深的工作的候选人，令我感到不可思议的是，有多少有经验的开发人员从未使用过探查器，而对性能调优或GC一无所知。 这是固有困难的结果吗？ 还是只是将性能视为事后才考虑？ 企业可以采取什么措施来纠正这一问题？
马丁（Martin） ：现在，回到咨询领域，真正令我感到惊讶的是，即使性能*是其领域的关键要求，很少有人对性能测试和调整有所了解。
本 ：我认为您提到的一些问题是相关的，并且与我们如何发展绩效工程师有关。 我最近看到了这句话，我认为这是相关的：
“培训教会人们如何更有效，更可靠地执行特定任务。另一方面，教育可以打开并丰富人们的思想。”
处理性能问题时，这两个方面都是必需的。 我们需要在表现分析和调优（这是培训方面）上向学生强调经验数据，统计数据和可重复运行的重要性。 但是，我们还需要他们了解如何将自己的经验应用于整个应用程序堆栈来解决性能问题（这更多是教育方面的问题）。
不仅如此，我们还需要引导他们摆脱“技巧”的表现（这更容易教授，因为它本质上是一种培训技术，而不是教育）。
最后，在进行教育或培训时，学生必须定期使用材料和新技能。 否则它们将再次萎缩。 进行为期12个月没有被用作核心职责的绩效课程基本上是没有用的。
柯克 ：前一段时间，我看到了埃里克·斯玛特（Eric Smart）的表演演讲。 他在讲话中指出了他们犯下的所有经典错误。 首先，重点是功能，功能以及更多功能。 他们是一群聪明的人，当需要整理时，性能会自行整理。 麻烦的是，当最终需要对性能进行整理时，它变成了一种练习，每天他们几乎都在那儿，只需要一点点时间，我们就可以完成一天，一天，一周，然后一个月，两个，三，然后四。 那时他们休息一下，问“好吧，这是怎么回事？” 他们意识到，不将性能作为日常工作的一部分，他们就忽略了小型设备中看不到的问题。 他们正在解决的正是这些问题，以至于该项目几乎失败了，并最终使公司失败。
这个故事有一个圆满的结局，因为他们能够将缓慢的失败转化为成功。 但是，突然发现，传统的发展道路并不能很好地为他们服务。
莫妮卡（Monica） ：在另一方面，公司聘请了一个名为“绩效工程师”的人，他们几乎收集数据（原始，日志或配置文件）进行比较，但是却不能花费大量的时间（由于缺乏知识或缺乏组织级别的承诺）对数据进行分析和“深入研究”以发现任何秘密的绩效问题。 另一端是绩效工程师，因为他或她在一个独立的团队中工作，所以不直接对产品进行投资，并且总是建议进行重大更改，而这些更改可能对于组织投资资源而言过于昂贵。 我认为在这种情况下，问题可能归结为对全面的绩效计划缺乏理解或明确定义。
话虽如此，我在整个职业生涯中都恪守组织层面的承诺，但是我认为相当多的组织必须致力于解决团队间的联系，而一些“绩效工程师”还必须致力于建立自己的知识。 也就是说，我还与许多精通性能的开发人员一起工作。 这就好比为一个组织赢得大奖。
性能调整是一门艺术。 有些从业者可能比其他从业者更有才华，但无论是谁承担的角色，都必须实践和完善这种艺术。 然后，我们的性能工程师必须将我们的知识传授给其他人。 这可以通过公开的论坛和会议以及直接与团队协商来轻松实现。
柯克 ：我想这一切都取决于您调整的意思。 试图弄清为什么应用程序未达到预期效果是一个诊断问题。 一旦诊断出状况，知道如何处理可能会落在两个方面：
我们之前已经看过了，解决方案已广为人知
我们需要想出一种新颖的方法来充分利用硬件。
因此，解决方案不仅取决于诊断能力，还取决于需要采取哪些措施来提高性能。 但是根据我的经验，一旦发现大多数性能问题就可以轻松解决，因此我认为最大的困难是诊断。
当我第一次听到马丁在Devoxx伦敦问“是否教过多少人如何使用探查器”问题时，我的第一个想法是“这是一个简单而又精妙的问题！” 我从来没有想过要问这个问题，因为我知道答案。 但是仍然需要指出这一点。 这应该是我们诊断工具库中的重要工具，但我不知道涵盖该主题的一所学校或其他机构。 有几所大学的教授与我联系，他们有兴趣探讨如何教授调音课程，但从来没有真正超越过。
回到难以调整的想法，我认为原因之一是它是一种诊断活动，因此与开发根本不同。 就其性质而言，它是一种调查，而就其性质而言，它要求人们进行测量。 不仅要进行任何测量，还要进行正确的测量，这是暴露问题的一种方法。 其中存在一个问题：如果一个人都知道如何使用它，那么应该如何进行正确的测量，那就是在IDE中运行的执行事件探查器。 但是，如果没有正确的度量方法，您将只能凭直觉进行其他猜测。 直觉的问题是，人们无法想象当软件最终遇到硬件和真实用户时发生的所有交互。 这种认识导致了杰克·西拉齐（Jack Shirazi）和我几年前提出的“测量，不要猜测”的口头禅。 这也导致我们在课程中教授我的Performance Diagnostic Model™。 PDM帮助我帮助开发人员将他们已经知道的内容重新打包为可以缓解诊断性能问题的麻烦的东西。
尽管PDM有所帮助，但通过我的示例练习，它仅成功地提高了成功率。 这是因为诊断还需要另一项技能，那就是能够使您的思维脱离细节而理解整体目的。 诊断像任何形式的故障排除一样，都需要您深入研究细节，有时难以重新定位以便获得更广泛的了解。 解决这个问题的方法超出了我的薪水等级。 但这肯定会影响人们遵循诊断过程的能力。
马丁（Martin） ：我们观察到“大多数不测量或不使用轮廓仪”。 但是我观察到了一个更有趣的现象。 对于进行概要分析并收集系统指标的团队来说，当他们查看数据时，似乎对他们没有任何意义。 我经常去找客户，他们告诉我他们有一个性能问题。 我问他们是否以各种方式对应用程序进行了概要分析。 在我的空间里，他们经常有探查器许可证，GC日志记录打开， 系统活动报告等。然后，当我向我展示数据时，我感到很惊讶。 答案就跳到我身上，他们似乎看不到它。 我花了一段时间才意识到这不是因为他们不聪明。 他们只是不知道如何解释数据，因为他们没有磨练这项技能。 这类似于我们使用调试器发现的内容。 当您的工作习惯每天都在执行时，它就变成了第二天性。 除非这几乎是一个障碍。
查理（Charlie） ：我同意莫妮卡（Monica）的定义，“绩效工程师”的定义似乎因公司和与您交谈的人而异。 在某些公司中，性能工程师是执行性能测试的人员，质量类型功能是他或她针对正在开发的产品运行性能工作负载并报告工作负载执行结果的人员。 改进，回归或无定论。 在其他情况下，性能工程师会采取下一步措施，并进行一些分析，以确定改进或回归的来源。 而且，还有另一种类型的性能工程师，他们不仅进行分析，而且还在寻找优化机会。 因此，我们观察到所需的各种角色，职责和技能。 我怀疑此小组中的每个人都属于后一类，并且我还相信正在开发应用程序的任何人都应该对他或她正在开发的产品的性能感兴趣，而不仅仅是将“性能”（或质量）视为别人的工作。 我曾经听过一位开发工程师说：“测试代码不是我的工作。这就是我们拥有一支质量和性能工程团队的原因。” 以我的拙见，那个工程师应该当场被解雇！
马丁 ：将性能工程师与“常规工程师”分开是一个巨大的反模式。 它由于多种原因而失败。 我完全同意功能和非功能需求的质量是所有工程师/程序员的责任。 但是考虑一下：在一次采访中我曾问过：“ HashMap和TreeMap有什么区别？” 如果他告诉我HashMap为O（n）而TreeMap为O（log n），我会很高兴。 如果他甚至解释了实现方式，我会很兴奋。 但是当他说“程序员不再需要那种东西了！”时，他的React让他很不高兴。 是的，拥有专家很棒，但是他们需要指导团队的其他成员来提出标准。
查理（Charlie） ：我认为困难不仅限于调整，分析和确定优化机会。 当您开始将性能工程的“科学”留给性能工程的“艺术”时，事情就变得困难了。 我会以类似的方式描述统计学的学科。 统计和统计方法都有“科学”，应用适当的统计方法也有“艺术”。 您可以教人们统计科学，各种不同类型的计算公式，但教给人们在特定情况下使用适当的统计方法进行使用的技巧是完全不同的。 以类似的方式，我们可以教人们性能工程学。 但是性能工程的艺术是完全不同的。 我认为那些真正在性能工程方面苦苦挣扎的人正在与性能工程的技术作斗争，但是不幸的是，这并不是一件容易的事情。
柯克 ：根据您的定义，我可能不同意。 当我想到艺术时，我想到的是无法衡量或难以量化的事物。 当我想到性能时，我想到的是可以衡量并且可以量化的东西。 在我的世界里，如果您说“艺术”，您真正的意思是“我在猜测”。 有些人可能比其他人更擅长猜测，但根据我的经验，这并不是因为他们能够凭空判断出答案。 而是他们拥有完善的思维模型，可以在其中插入可用数据并获得更高质量的答案。 我在课程中看到了这一点，在这里我提出了一个数据量最少的问题，并且看着开发人员在努力。 然而，在为他们提供了一种可以突然使用的思维模型之后，这些最小的数据量却激起了问题的答案。 线索无处不在。 我们只需要能够识别它们即可。 我不认为这是艺术。 这是关于了解度量表示的内容。 “艺术”正在提出新颖的方法，以从我们当前必须使用的硬件中获得更多收益。
查理 ：当我说艺术时，我并不是要猜测。 性能工程中的一种艺术形式是模式匹配。 您在课程中所做的描述是在尝试提供性能工程学，然后教授性能工程学。 知道要测量/监视的内容，知道指标的阈值的行为值得进一步研究。 知道使用什么工具并将其吸收到根本原因是我所说的艺术 。 它知道如何在正确的情况下应用正确的性能工程方法。 如果这是科学，则可以进行数学建模。 正如您所描述的，“心理模型”就是我所说的“艺术”。 知道猜测或推测的内容，缩小猜测的可能性或进行有根据的有根据的猜测的方面，或者知道做出明智的决定所需的其他数据属于我所谓的绩效艺术工程。
柯克 ：是的，我发现另一个坏习惯是人们经常得出不一定从数据中得出结论的结论。 他们在猜测或推测，或者在我的书中只是猜测！ 我可以举一个例子。 在垃圾回收之后，堆图中的向上倾斜曲线意味着内存泄漏，对吗？ 我说这是基于推测的过度结论。 我可以将错误的地方发送给您的GC日志。 我怎么知道区别，这不是艺术，我只是问意图。 所有这些都是算法的吗？ 是的，我相信是的。
查理（Charlie） ：也许要考虑的一个问题是：为什么大多数大学在向软件工程专业的学生教授数学和计算理论之前就向他们教授编程语言？ 与其他工程学科（例如机械工程或工业工程）相反，在这些学科中，首先向学生教授其学科的数学和理论。
柯克 ：我不想低估统计数据的重要性，但是通常，通过排队论可以更好地描述计算机系统中发生的事情。 据我所知，很少有软件开发人员或测试人员对排队理论非常了解。 我认为您不需要对该主题有深入的了解，但是有必要有所了解并知道如何应用它。
查理（Charlie） ：我一直将排队论视为统计研究/学科的一部分。 我第一次接触排队论是在统计学课程中。 请记住，您使用排队论建模的大部分内容都是基于概率密度函数，即泊松，指数分布和其他分布。
马丁（Martin） ：虽然我在很大程度上同意查理（Charlie）和他那三腿的性能折衷，但是我发现这在某些情况下是有害的。 在考虑运行时和GC时，是的，它适用得很好。 但是考虑数据结构时，占用空间小通常意味着低延迟和高吞吐量。 为了提供一些背景信息，我研究了吸收整个北美金融市场供稿的系统，该系统可以维持每秒超过1100万条消息的周期。 考虑到现代x86服务器的体系结构，我们仅对L1缓存上的大页面（2MB）具有TLB缓存支持。 L2缓存仅具有用于4K页的TLB缓存。 英特尔即将发布的Haswell芯片将于明年面向服务器推出时，将在L2缓存中支持2MB页面。 当其余代码有效时，这可能成为主要问题。 由于预取器的原因，我们没有注意到扫描GC卡表的情况，但是对于大多数其他数据结构而言，这是一个主要问题。 我想我说的是主流的良好通用规则，但在更高端，其他事情可能变得更加重要。
InfoQ：组织应投资哪些工具和技术以将绩效分析纳入主流？
莫妮卡 ：首先，正如我提到的，是绩效计划。 二是建立绩效基础设施。 性能测试应该是产品生命周期的一部分。 因此，必须投资于强大的性能基础架构。 许多组织会因为没有领先于游戏而陷入困境，在知道之前，他们需要投资更多的资源来“修补问题”。 对于组织或其员工而言，此行为是不健康的，非生产性的并且资源效率不高。
查理 ：最近我一直在考虑这个问题。 你们中的一些人可能听说过我在吞吐量，延迟和占用空间方面谈论性能。 当谈到满足应用程序的性能目标时，我已经开始向产品团队和赞助执行人员提出八个问题：
预期吞吐量是多少？
您可以承受的最低吞吐量是多少（不低于此值）？吞吐量下降到该级别的频率如何？持续多长时间？
什么是吞吐量指标，如何衡量？
预期的延迟时间是多少？我们可以多久才能超过该值？持续多长时间？
您永远无法超越的延迟时间是多少？
什么是延迟指标，如何衡量？
可以使用的最大内存量是多少？
如何测量内存使用情况？
我注意到有些公司和组织未能适当地获取适当的指标。 这是我最近看到的一个示例（顺便说一下，不是在Salesforce上 ）。 假设您有兴趣减少内存占用。 但是性能标准不仅是减少内存占用，还不需要增加CPU利用率，不减少吞吐量和不减少响应时间。 如果真是这样，那么实际上是您正在尝试实现内存占用量的减少，但不愿意牺牲吞吐量或延迟方面的任何东西。 祝一切顺利！ 要强调这些属性之一的改进，在此示例中，在保持吞吐量和等待时间不变的同时，内存占用量将需要大量/不小的开发工作。 您很少会在不牺牲其中一个或两个其他属性的情况下实现其中一个性能属性的改进。 令我惊讶的是，很少有人能理解这种关系。
一个类似的问题是如何对应用程序进行测试？ 您如何捕获预期和计划的生产用途？ 我认为您必须了解并描述应用程序的最坏情况下的性能行为，尤其是当您要构建的平台是供其他人在其之上构建应用程序的平台时。 此外，您还需要捕获应用程序的预期和预期生产使用情况的性能。 您还需要关闭作为工作负载开发的内容与应用程序在生产中的性能之间的循环。 换句话说，根据这三个性能属性，工作负载在预测生产性能方面的效果如何？ 我很少观察到有人关闭这个循环并衡量其工作负载的有效性。
柯克 ：很棒的清单。..我要补充一点，我们处于一个遭受“ CPU羡慕”之苦的行业，而CPU常常不是问题所在。 因此，了解我们正在使用的硬件的基本限制并将其与我们实际需要的资源相关联是一个巨大的问题，很少有人能够解决。
我认为我们将看到越来越多的性能问题，而不仅仅是与CPU有关。 如果我们还没有经历或观察过它，我想我们可以预期会出现诸如内存总线容量之类的问题，或更普遍地说，我们可以从内存中将数据获取到CPU缓存的速度。 内存是新磁盘。 每个CPU插槽具有大量硬件线程的一大挑战是拥有足够的内存总线容量以及足够的CPU缓存。 两年前，我已经观察到一个多核系统，在达到任何接近峰值CPU使用率之前，它都会使内存总线容量达到饱和。 今天有多少人会知道如何测量内存总线容量，甚至想到测量内存总线容量？
我可以告诉您最后一个问题的答案，因为我一直都在问那个……没人！ 但是，几年来，我一直在遇到受该资源约束的应用程序。
马丁（Martin）：我们已经达到了行业朝一个方向过度发展的地步。 我们正确地一直在努力提高开发人员的生产力和交付的可预测性，但这付出了代价。 现在，我们生产的软件效率很低，以至于我无法想到可以容忍这些低效率水平的任何其他行业。 通过采用更简洁的设计和一些由性能分析驱动的调整，我们的许多软件可以将吞吐量提高10到100倍，或将延迟降低。 在某些情况下，我已经看到1000倍的改进。 我们的数据中心成本现在变得越来越高，而二氧化碳排放量的2-4％现在与计算有关。 我们还必须考虑移动设备的爆炸式增长，在这些设备上高效的软件可以直接转化为节电，并且减少了提供主要基于服务器计算的移动服务的服务器。
举报
