“应用很慢，你可以确保它快速吗？”
上面的引用应该会让任何有经验的工程师感到脊背发凉。这里的“快速”的具体含义是什么?
除非你对“快速”部分有一个定义，否则你将永远陷入优化周期，因为每个应用都可以不断的被创建的更快一些。然而在现实生活中，性能并不是唯一一个需要我们完成的要求。所以为了能提供最大的价值，我们应该知道什么时候该停止性能优化。或者更重要的是，引导我们的性能目标应该是什么样的。
功能以外的需求
企业已经越来越好的表达软件的功能需求。但是考虑到功能需求以外的事情，比如可用性、兼容性或者性能，这个时候企业主的描述常常是相当于一片空白。而这片空白最常见的形式就是“确保它快”或“有没有更好的情况”，你对此会有类似于一下的处理方式：
95%实施在系统内的业务的响应时间必须在5秒内；
系统必须支持100个并发用户。
相比较“确保它快”来说，以上两种方式咋一看并不坏，毕竟它让你有了一个明确的引导目标，不是吗？事实上，上面的比“快”更糟糕。因为它包含了一些看起来可以用作终极目标的数字。
实际上，这些数字充其量只能作为基础使用。你可以从这两个出发扩充需求。
95%实施在系统内的业务的响应时间必须在5秒内
剩下的5%是什么？响应时间变为10秒或更多可以吗？所以在设定的时候不要固定单一的目标，应该有一个可接受的延迟分布：
“显示我当前账户的结算”。这个每天可能会被执行数百万次，因为每个零售客户都会与银行互动。
“显示我的账户在2013年的所有交易”。这个相比较前面的执行次数要少很多很多。
对于上面两种情况我们设定的目标应该是不同的，第一种响应要求要比5秒短，而第二种则可以适当的放宽要求。
当使用到测量值时系统的负载是什么？有多少其他操作可以同时进行？这些都是你应该连接潜在相关的加载/吞吐量需求的地方。
响应时间是在终端用户环境中测量的吗（如浏览器响应或Android应用更新结果）？或者测量是按照最后一个字节从服务器端发出时算的？为了避免含糊不清的定义测量标准，在这里我们需要对延迟测量精确化。
批量处理作业/异步流程？每个月批量处理计算最终信用卡余额的延迟时间是两小时还是5秒钟？对于大型业务完整的财务报表异步的存入到CSV中并在10分钟后通过邮件的方式发送？所以，明确一件事的操作延时是否要紧也是重要的。
通过以上几段的分析，我们可以将第一种方式的性能描述细分为：
对不同的情况制定不同的延迟目标；
连接相关的加载/吞吐量需求；
对延迟测量精确化？即测量的标准是什么；
确定该项操作是否紧要。
系统必须支持100个并发用户
100个用户通过CDN每10秒点击一次你网站的静态图片，我想你闭着眼睛就可以构建这样的一个系统。100个用户同时在你的网站上编码4K视频文件，这时候就难以想象了。
当考虑到真正的并发性时事情从模糊转向了毫无意义。比如将“100个并发用户”理解为“100个操作并发的被100个线程处理”。假设每个这样的操作过程需要10秒，然后系统的吞吐量为10ops/sec。如果你现在缩短10倍的操作时间，即每个操作过程需要1秒，系统的吞吐量将提高到100ops/sec。但是你会发现前一种并不满足“100个真正的并发用户”需求，只同时处理10个操作。这是一个失败的需求
取代“并发用户”或其他类似的条款，这类需求应该更清楚的表达某些用户的行为。将这些描述转化为潜在的负载测试，以允许你模拟所需要的负载。
在这里不推荐测量吞吐量，现实生活中的应用往往是多功能的并被用于动态情况。这使得很难通过吞吐量来表达性能目标。但是如果是特定的只用于某件事的应用，如发票支付，吞吐量就成了衡量特定目标的好方法。
产能计划
你的应用应该满足性能要求的数据量是多少？要清楚系统中存在的数据量。
关于基础设施的约束是什么？比如内存、CPU的方案等， 知道这一点可以帮助你了解基础设施的限制。
应用部署的环境是什么？比如网络带宽是多少，是否支持离线操作等。你需要了解你应用将要部署的环境需求。
结论
以上所列的描述是不完整的。举例来说，当涉及到可伸缩性和可用性时，你会面临一个全新的要求。本文旨在抛砖引玉，在你下次遇到模糊定义的性能需求时，你会有一系列的问题扩展这些模糊的需求。
与业务者的沟通有助于你发现可衡量的、特定的目标。从企业者来看，自然是希望所有操作的“超快速”。而为了实现这一目标，无外乎还是要归结到成本上。你说呢？
