你真的知道如何定义性能要求么？

【编者按】本文作者是 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 官方博客。
本文转自 OneAPM 官方博客