【编者按】本文作者是 Nikita Salnikov Tarnovski,是 plumbr 的联合创始人,作为一名高级开发者,他同时也是一位应用性能调优的专家,拥有多年的性能调优经验。本文中他通过常见的性能需求误区经验,分享应该如何去设定实际的性能需求目标,本文系 OneAPM 工程师编译呈现。

以下为译文:

「这个应用跑得太慢,你能让它快起来吗?」

——企业老板这样说道

如果你是个经验丰富的工程师,对这种场景肯定不陌生,一听到这种话,整个脊椎不寒而栗。笔者一直强调用「测量不猜测」的观点处理性能优化问题。这意味着你要先明确经理所指的「快」是什么。如果没有这个定义,你可能永远都会困在优化周期中,因为每个重大应用总能在某些方面得到改进,从而提高速度。

现实生活中,性能并非是亟待解决的唯一任务;为了提供最有价值的产品,我们应该知道什么时候应该停止性能优化。更重要的是,我们应该清楚地知道我们的性能目标是什么,并有一个明确的规划去实现之。

错误定义的性能需求

相对之前,企业老板在表达软件功能需求上已经有所进步。但在功能性需求之外——比如应用的可用性、兼容性或性能——老板心里其实完全没底。这个空白常常用「确保它够快」这种模棱两可的话,或者与下面类似的要求表达出来:

  • 系统内95%的业务操作必须在 5 秒内得到响应

  • 系统必须支持 100 个并发用户

乍一看这些要求,你可能会觉得没那么糟。不再一直念叨着「快快快」,你现在至少有了一个明确的目标,对吧?事实证明,上面的目标甚至比「快快快」的念叨更加糟糕。虽然它包含了一些可以设为终极目标的具体数据;但实际情况下,上述两点要求最多只能作为提出更好优化问题的基础。下面解释这些要求的错误之处。

95%的业务操作必须在5秒内得到响应

剩下的五个百分点要怎么办?如果将响应时间设为10秒,这个目标是否切合实际呢?连接超时也可以吗?其实,你应该避免将时间设定为唯一目标,而是设置一个可接受的延迟分布范围。这个要求的另一个问题是,它将所有的操作等同化。如果有95%的操作在4.9秒内反应,就万事大吉了么?即便这些操作的速度还可以更快?以下面这些操作为例:

  1. 显示我当前的账户余额:这个操作每天被执行数百万次,也是每个零售客户与银行互动的第一个问题。
  2. 显示2015年的所有交易:每天仅有少数用户执行该操作。

显然,你需要区别对待不同的操作,对第一个操作有更高要求,而第二次操作可以有更宽松的要求。因此,你应该为每个操作类型设置可接受的延迟时间分布,而不是对所有操作一视同仁。

你还应该将延迟需求与加载/吞吐量需求联系起来。因此在进行性能测量时,应该找出系统中的负载,并发掘有多少其他操作可以同时执行。然后用这些信息来构建延迟需求。

精确延迟测量的层。是在终端用户的环境中进行响应时间测量呢 (比如,浏览器呈现响应时或一个安卓应用更新结果时)?还是当最后一个字节从服务器端发送后进行测量呢?

大多数软件总是可以优化得更快,问题是它在经济上是否可行。

最后,你应该确定哪些操作完全不用担心延迟。批处理作业和异步流程就是很好的例子。每月运行的批处理任务需要两个小时来计算最终的信用卡余额,不应该视为违反了5秒阈值。完整的会计 CSV 报表通过电子邮件发送得等到10分钟后,属于异步编译,也不应该视作违反标准。

系统必须支持100个并发用户

设想一个网站有100个用户在线,每次点击静态图像都通过 CDN 进行呈现需要10秒时间——我打赌你闭着眼睛就能构建出这样一个系统。但是,100个用户同时在网站上编码 4K 视频文件则要另当别论了。

当考虑真实并发性时,事情从模糊不清变得毫无意义,比如将「100个并发用户」翻译成「100次由100个线程并发处理的操作」。假设每一个这样的操作需要10秒的处理时间,那么系统的吞吐量就是每秒10次操作。如果现在将操作时间减少十倍,每个操作只需1秒钟,你就已经将吞吐量提高到100次操作/秒。然而,你并未实现 「100个真实并发用户」的要求,只是并发处理10个操作,这意味着你未能满足性能要求。

其实,在表达用户的具体行为时,应该避免「并发用户」或任何类似的术语,要求应该更加明确,尽量将这些描述转化为可以模拟所需负载的负载测试。

需要注意,笔者并非建议你测量吞吐量。这其实没多大用,因为现实生活中的应用通常是多功能的、应用于动态的状况。所以很难明确表达出吞吐量的性能目标(每小时的操作量)。但是,如果一个应用被特定设计为只实现一个功能,例如发票支付,那么,设置类似于「1000个发票/分钟」的吞吐量目标,是非常好的可测量的具体目标。

容量规划

容量规划是你应该精确指定的另一重要性能需求。你的团队是有望实现上文提到的目标——数据库中容纳一万个帐户和一千万个事务?或者期望系统满足一百万个账户和十亿交易这些条件?请明确系统中储存的数据量。

别忘了明确有关基础设施的经济约束。你是否准备使用价值 500美元/月的 AWS 实现你的性能要求?或者你能财大气粗地在32核和几 TBs 容量的高端配置上部署解决方案?知道这些问题的答案可以帮助你了解基础设施能承受的性能目标。所以在确定性能需求之前,你应该明确基础设施的限制。

在制定性能需求时,还应该考虑客户的网络带宽限制。网络带宽是否能接受对操作发送几个 MBs 来回的要求?移动应用固然使用广泛,但你不能指望每个客户都使用全能的 4G 网络,所以应该构建一组离线操作,可以在本地进行处理,从而将流量从兆字节转换为千字节。

结论

本文所描述的各个方面还不够完整。在可伸缩性和可用性方面,还有许多性能方面的考虑,可以引导你进一步完善需求。即便如此,你应该更仔细地审视模糊的性能需求,列举出能落实到现实需要的问题。和企业老板合作制定可测量的具体目标。否则,你就没有真正的目标去实现并衡量结果。

通过这个过程,也可以了解相关的成本。企业老板总是渴望更详细地了解成本!如果你还记得,大多数软件总是可以优化得更快,问题是它在经济上是否可行。从企业所有者的角度来看,他们自然想让所有操作都尽可能快。但只有当我们了解了实现目标的成本限制,才能设置更为现实的期望。

OneAPM应用性能管理领域的新兴领军企业,能帮助企业用户和开发者轻松实现:缓慢的程序代码和 SQL 语句的实时抓取。想阅读更多技术文章,请访问 OneAPM 官方博客