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

【编者按】本文做者是 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 官方博客