JVM 监控解决方案提供商 Plumbr 的官方博客上发表了一篇题为《如何定义性能需求》的文章。文章指出，随着企业信息化程度的提高，业务人员对软件功能性需求的描述越来越好。但涉及到易用性、兼容性或性能等非功能性需求的时候，他们经常会不得要领。比如，他们可能会提出“它的运行速度要快”这样的性能需求。在更好的情况下，他们可能会提出下面这样的性能需求：
- 在系统中执行的操作，95% 的都必须在 5 秒针内响应；
- 系统必须支持 100 并发用户。
初看上去，这样的需求已经好了很多了。但实际上，它们甚至比只用一个“快”字描述更差。虽然它们包含了一些数字，看上去似乎可以作为开发人员的终极目标。但实际上，这两个需求最多只能为关于性能需求的讨论开一个头。
文章接下来对上述两个需求进行了剖析。
第一个需求没有提出针对其它 5% 的操作的性能需求。而且，不同的功能对性能的需求也不尽相同。比如，对于功能“显示当前账户余额”和“显示 2013 年所有的交易”，前者 5 秒响应可能都略显慢，而后者响应时间再长一些也可以接受。因此，性能需求描述应该：
- 针对不同的操作类型指定可接受的时间延迟；
- 将时间延迟相关的需求与负载 / 吞吐量相关的需求联系起来；
- 明确时间延迟的测量位置，比如，延迟时间是以客户端为标准，还是以服务器端发送出最后一个字节为标准；
- 哪些操作的时间延迟不太要紧。
第二个需求看上去很准确，实际上很笼统。比如，将“100 个并发用户”理解成“100 个线程处理 100 个并发操作”。如果每个操作用时 1 秒，那么系统吞吐量为 100 ops/sec；但如果每个操作用时 10 秒，那么系统吞吐量则只有 10 ops/sec。对于后一种情况，我们不能认为它满足“100 个并发用户”的需求。因此，需求应该更清楚地描述特定用户的行为，而不是用“并发用户”这样的术语。当然，这里并不是说建议测量吞吐量，因为现实世界的应用程序往往是多功能的，很难使用吞吐量来衡量其性能。
本文还提到了容量规划，即在什么样的前提条件下实现上述性能需求，包括如下三个方面：
- 系统的数据量；
- 系统的基础设施限制，比如，CPU、内存等；
- 系统的部署环境，比如，网络带宽是多少，是否需要离线操作等。
总之，应该与业务人员紧密合作，制定出可测量的、具体的性能需求。
感谢郭蕾对本文的审校。
给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。
评论