掌握Java性能知识：Kirk Pepperdine访谈

Kirk，多年来，您一直是Java性能调优的先驱； 我想谈谈您用于加速基于Java的系统的“秘密秘方”。 但是首先，您能否让我们了解一下您在市场中看到的不同领域，以及哪个领域最注重性能？

我需要在这里纠正一些问题。 真正的先驱是杰克·西拉齐（Jack Shirazi）。 他写了第一本关于Java Performance Tuning的真实书籍，内容超出了仅与当前版本一样好的技巧。 我确实在那本书上有帮助，但是是杰克把这本书放在一起了。 首先要回答第二个问题，我认为几乎所有域都面临着期望系统越来越快的用户。 并且，期望系统保持并处理越来越多的数据。 一个更笼统的问题可能是； 与竞争对手相比，我能为客户提供更好的绩效概况吗？ 或者，如果有交易机会，我的系统是否调整得足够好，以至于我总是会赢得比赛？ 考虑到这个问题，我会说很少有领域的性能并不重要。

现在为秘密食谱。 首先是大秘密，没有秘密。 性能就是了解硬件并与之合作以充分利用硬件。 就是这样，当我与Cray超级计算机一起工作到今天处理日常普通商品硬件时。 有人说，硬件要快速发展，而您所要做的就是保持现状。 了解了它的工作原理后，您将更好地了解如何避免这种情况。

性能显然是一件复杂的事情–一方面，有很多调优方面，所有的细节都在Java的核心级别上；另一方面，它在Java的核心级别上发挥了作用。 另一方面，存在系统的端到端视图（从数据存储到最终用户界面）。 您能给我们一个提示，告诉您通常应该从哪里开始？

性能调整有两种类型，自上而下和令人惊讶的自下而上。 最大的收益总是来自自上而下的调整。 也就是说，从最高的角度看待系统，找到延迟预算的最大使用者，然后将精力放在目标上。 听一下硬件，它将告诉您如何进行操作。 这样，您应该始终知道在哪里以及为什么。

还请参见： 关于Java的十件事

对于自下而上，您想从硬件级别开始，并让它告诉您如何进行。 在这里我们可以查看MSR或机器专用寄存器。 这些是CPU内的特殊诊断寄存器，可以为您提供重要信息，例如高速缓存命中率/未命中率，指令退出率等。 再说一次，没有秘密秘方，只是告诉我我在哪里，这样我就可以躲开。

在云时代，仅添加更多系统实例比在内部进行调整难道难道不是吗？ 换句话说，更多的资源（以前的CPU，现在是Cloud时代的实例）在何种程度上提供帮助，并且在核心软件级别上只有Swiss Precision可以在哪个领域提供帮助？

当然，云计算的巨大胜利在于，它可以减轻管理负担，并使其更易于扩展。 但是，如果您尚未构建可扩展的系统，则将无法使用额外的硬件。 另外，在使硬件负担过多之前，您只能在单个硬件上投入太多资源。 虚拟化不会为您购买更多硬件。 这意味着您必须知道您的应用程序将与在相同物理硬件上运行的任何其他应用程序相处。

我已经看到了与Oracle DB在相同硬件上的VM中的关键任务应用程序。 无论如何切片，这都根本行不通。 我还看到了其中一种资源或另一种资源（通常是网卡）被完全超额认购的盒子。 此外，浪费云实例就像浪费任何其他资源一样，您不会看到很大的投资回报率。 是的，云非常有用。

也就是说，它们不是谚语的灵丹妙药。 您仍然需要谨慎配置硬件。 当然，在当前的要求下，如果对延迟的要求很低，则必须非常小心。 实际上，对于超低延迟的熊金属仍然是必需的。

分布式系统，或者说微服务（倾向于将复杂性从整体内部转移到网络）又如何呢？

天哪，这项技术的转变很有趣。 我刚刚回应了Eberhard Wolff发表的一条推文，他在其中定义了微服务。 根据这个定义，我们早在还没有想到Java的时候就已经在构建具有微服务的系统。

在92年，我正在研究一个被描述为基于微服务的系统。 即使按今天的标准，它也是一个构建良好的系统。 通过微服务的所有工作流程都可以用DSL指定，所有微服务都可以在计算集群中迁移。 非常灵活，非常非常有弹性，并且在需要时可以很快执行。 唯一的缺点是网络，而这将是今天的缺点。

“天哪，这项技术的转变很有趣”

如果您的工作量不足以抵消网络分发成本，那么网络延迟将是主要成本。 这是巨大的代价。 有人可能会说会导致您不分发微服务的费用。

当您咨询欧洲和世界各地的许多不同的开发团队时，您是否会说社区中存在良好的绩效智慧？

这里有几个不同的问题。 首先让我来回答一下。 我要说的是，一般来说，每个团队的绩效智慧水平都很高，这是每个团队大部分时间所需要的。 团队遇到困难是指他们无法意识到自己遇到的问题超出了他们所能解决的范围，或者他们等待了太长时间寻求帮助。 我可以举一个例子。 不久前，我接到一家公司的电话，该公司拥有一支非常强大，注重性能的开发人员小组。 他们遇到了一个问题，即应用程序的响应时间突然增加了5倍。 在最终伸出援助之手之前，团队花了几个月的时间为这个事业奋斗。 诊断花费了几个小时，并且涉及查看很少甚至不知道存在的JVM的一部分，更不用说知道其功能了。 那是我对公开问题的回答。 隐性问题更多是关于教育系统无法提供更多诊断技能培训的问题。

据我所知，没有一个专上学院提供性能调优课程。 他们非常擅长为人们提供建筑系统的事实和秘诀，但是课程中关于如何执行诊断的巨大漏洞。 在本科级别上，科学方法，统计分析和绩效基准的重要性几乎没有关系。 Uni的本科课程几乎都集中在过早的优化上，例如合并排序比气泡排序更快，并且Omega表示法提供的性能评估假定在静态运行时进行静态编译。 有一些大学希望将其添加到课程中，但是到目前为止我还没有看到任何东西。 因此，这使人们有调优的任务，但没有合适的工具来执行任务。 他们在做什么？ 他们继续前进，经历混乱，而工作往往完成得更多。 就是说，如果他们有了一些正规的流程来帮助他们，他们的效率就会大大提高。

我认为，这是我提供的一个分手，它是将性能调整过程正式化的方法的起点。 我不主张该方法论是完整的，也不主张这是进行下去的唯一方法。 但是，这种方法已帮助许多人将结构和可预测性带入了性能疑难解答的混乱之中。

Kirk Pepperdine将于2015年3月26日在柏林的Java Code Camp上发表演讲

翻译自: https://jaxenter.com/interview-with-kirk-pepperdine-114737.html