”

本文根据Gil Tene在2015年QCon上海站的主题演讲内容整理而成。 2016 QCon 北京将于今天上午在北京国际会议中心举行。小Q将通过微信公众号实时传播更多会议有用信息。还有免费的直播视频，不信的话看看下面的文章！

Gil Tene 是 Azul 的联合创始人兼首席技术官。过去25年他一直从事虚拟机和运行时技术的开发。他的主要兴趣是研究系统响应和延迟行为。吉尔经常在世界各地的技术会议上发表演讲，是一位明星演讲者。作为主要作者，他提出了C4()垃圾回收算法，这也是Azul反应式Java平台的基础。

擅长Java虚拟化、弹性内存、各种托管运行时等技术。他是著名的Java和JVM专家。过去还从事操作系统、网络交换机、防火墙等系统的设计和构建。此次他在QCon演讲的主题是“”，分享了他如何从务实的角度看待“表演”。

我今天分享的并不是告诉大家如何衡量数据或者如何调优。这些年来我犯了很多错误，但我很幸运能够从其中一些错误中学到新东西。这些就是我今天想和大家分享的内容。希望大家反思一下自己对“表现”的理解，以及我们面对“问题”时的思考方式。

“实践”一词是相对于“理论”而言的。解释“实用”和“理论”之间差异的最简单的例子就是看屏幕上的这辆跑车。如果你问这样的问题：

“这辆车能跑多快？”

所以你问的是它的“理论速度”。您得到的答案可能是 189 英里/小时。这个速度完全取决于汽车发动机的极限速度、汽车的外观设计等因素。

如果你问另一个问题：

“跑车和电动自行车哪个更快？”

这也是一个关于“理论速度”的问题。应该从“实际”角度提出的问题是：

“周五上午9点的北京四环路上，这辆跑车和电动自行车哪个更快？”

或者：

“周五晚上9点，这辆跑车能在北京四环路上跑多快，而不发生交通事故？”

今天，我们这些制作软件的人经常会问类似的问题。例如：

“这个系统/工具每秒可以实现多少个查询？”

这是一个过于简单化的“理论问题”。这个理论问题的背后，隐藏着无数可能的“实践”问题，每个问题都有自己的边界或前提。在讨论问题本身之前，请务必仔细思考有关问题本身的一些重要问题，例如：我是否需要回答每个具体问题并提供正确答案？我可以只回答简单的问题吗？我们是否必须在下周内提供数亿个答案？

在比较系统性能时，避免将苹果与橘子进行比较。例如，系统A的理论性能是每秒处理X个请求，但无法满足某些场景的需求；系统B的理论性能为每秒处理0.9X个请求，可以满足所有场景的需求。此时我们不能说“系统 B 更慢，但更可靠”。这种比较是没有意义的。真正有意义的比较是在满足所有要求时获取系统 A 的真实性能，并将其与系统 B 在相同条件下实现的性能进行比较。

当我们谈论系统性能时，我们经常使用以下指标：

这样的指标可以有很多，而且它们会互相影响。例如，在一种场景下，您需要系统在停机后1小时内恢复。后来需求变更为需要1分钟内恢复。如果我们要评估修改后的系统，我们不能只看它的恢复时间是否达到1分钟后，我们还得看其他指标——每秒执行次数、延迟和停机率——是否仍处于之前的状态。

以下是示例。比如我们对系统有这样的要求：无论场景多么繁忙，99.9%的请求必须在20毫秒内返回。那么，如果系统处理一个请求需要100微秒——相当于每秒1000次的处理能力，这样的系统能满足我们的要求吗？

答案很简单：“有可能”。想象一下，如果 1 毫秒内输入 50 个请求会发生什么？

上图是来自我们在线系统之一的真实数据。横轴为时间，跨度为1天，刻度为1秒；纵轴表示“这一秒的第一毫秒内输入的请求数”。蓝色部分是记录值，红色横线是根据系统处理能力得出的理论最大处理能力。可以看到，很多时候，蓝色峰值超过了红线。

然后我们当然会使用“排队”方法来处理这些峰值请求。但当我们使用队列时，我们必须澄清一个问题，那就是我们衡量的“响应时间”是否包括排队时间。经常发生的情况是，我们测量的可能是“服务处理时间”而不是真正的“请求响应时间”。

就像你去星巴克买咖啡一样，服务员泡一杯咖啡的平均时间就是“服务处理时间”，而“请求响应时间”是从你开始站在门口开始计算的。排队的最后等待购买咖啡。事实上，当我们在请求数频繁大于处理能力的高峰期查看真实的延迟数据时，往往是这样的：

我们总是开始测量得太快。一开始我们确实得到了一些测量数据，但在生产环境中，我们常常对系统的实际性能感到惊讶。

那么在“衡量绩效”之前我们应该做什么呢？一是明确需求。所有需要进行性能测试的系统至少应该是正确的，即功能上正确、满足用户对可用性的要求等。如果系统本身存在错误，那么性能测试的结果无论如何都是无效的。另一个是认识到环境的局限性和边界。

我要讲的下一个主题是与垃圾收集（GC）相关的。俗话说，GC的使用会影响程序的性能。在需要性能的地方建议使用 C/C++/-C。但今天我想请大家从“务实”的角度来思考一下绩效问题。

看看这三种交通方式。宇宙飞船和电动自行车哪个更快？按照理论速度来比较，答案是无疑的。

但我再问一下：哪种交通方式可以让我在15分钟内从家里搬到工作地点？

或者：按照我需要的速度，我现在或者最迟6个月内可以使用哪种交通工具？

说到GC影响程序的性能，其实主要是考虑到“资源浪费”这一层。这个想法实际上可以追溯到计算机发展的早期。我也经历过那个时代，那是三十年前，我的存储被视为宝贝。如果我今天看到它，我可能会把它当作一座宝山，但更大的感受可能是“愤怒”。

为什么？这么小的多核机器，拥有大量的存储空间和如此分辨率和颜色的屏幕，是用来做什么的呢？打电话吧。听音乐。你在开玩笑吧？你用这么宝贵的资源来做“听音乐”之类无聊的事情？

这是两个完全不同的概念。三十年前，计算资源被认为是宝贵的，因此“节省使用”是正确的做法。如今，计算资源被视为白菜，“浪费”才是出路。事实上，正是因为我们把计算资源视为白菜，硬件才能发展到今天如此之快。

那么对于今天的节目来说，什么是“更高的性能”呢？那不是最节省计算资源的软件，而是浪费最多计算资源但节省最多时间资源的软件。因此，请随意浪费这些计算资源！

赠送复活节彩蛋！

感谢人友出版社、图灵教育异步社区的大力支持！最后一波书单彩蛋，《七周七个并发模型》。本书作者也将在QCon北京进行精彩分享。今天之后，所有获奖用户都将陆续获得精美技术藏品。

参与规则： 非常简单！请在本文评论区留下你足以打动小Q的见解，无论是关于书还是文章。评论获得最多点赞的五个人是获奖用户。活动结束后会陆续发售，不用担心！

本文为原创发表，未经授权严禁转载。