如何定义性能要求？

“该应用程序运行缓慢，您可以确保它运行很快吗。”

上面的引用应该使任何有经验的工程师不寒而栗。 在我们以前的文章中，我们在处理性能调整时不断强调“无法猜测”部分。 更重要的是要定义“ 快速 ”的含义。

除非您对“ 快速 ”部分有定义，否则您可能会在优化周期上花费大量时间，因为在某些方面，每个不重要的应用程序总是可以变得“ 更快 ”。 不幸的是，在现实世界中，性能并不是我们需要满足的唯一要求，因此，为了提供最大的价值，我们应该知道何时停止性能优化。 或更重要的是，性能调整活动应将我们带向哪些目标。

定义不明确的性能要求

在表达软件功能要求方面，企业主越来越好。 但是，当在功能需求之外（无论是可用性，兼容性还是性能方面）进行思考时，企业主的想法常常会成为空白。 此空白处可以采用“ 确保快速 ”的形式，或者更好的情况下，您将具有与以下类似的功能：

• 系统中执行的95％的操作必须在5秒内响应
• 系统必须支持100个并发用户

乍一看，您可能会认为“还不错”。 现在，您已经有了一个明确的目标，可以直接转向，不是吗？ 事实上，以上情况甚至比“ 快速 ”还差。 由于它现在包含一些数字，因此看起来它可以用作最终目标。

实际上，以上两个要求充其量只是您开始提出其他问题的基础。 让我提出这些要求的问题。

剩下的5％应该怎么办？ 目标是将响应时间设置为10秒，还是可以使这些连接超时？ 而不是固定一个目标，您应该设置可接受的延迟分布 。

如果您真的将所有操作都视为等效操作，例如，在两种情况下都可以在4.9秒内返回95％的请求就可以了：

• “显示我的当前帐户余额” –一天可能执行数百万次，这是每个零售客户在与银行互动时遇到的第一个问题。
• “显示在2013年期间从我的帐户中借记或贷记的所有交易” –在更多奇特的用例中，一天只需要几次。

我认为您将需要对第一个操作进行不同的处理，并且对目标的要求更高，可能会放宽对第二个的要求。 因此，应将每种操作类型 （或操作类别） 设置为可接受的等待时间分布 ，而不是将所有操作等同处理。

进行测量时系统中的负载是多少？ 可以同时进行多少其他操作？ 在这里，您应该将与延迟相关的需求链接到与负载/吞吐量相关的需求 。

响应时间是在最终用户环境（例如，浏览器呈现响应或Android应用程序更新结果）中还是从服务器端发送最后一个字节时测量的？ 与其模棱两可地定义测量标准， 不如精确地测量延迟 。

批处理作业/异步过程呢？ 运行2小时的每月批处理作业计算最终信用卡余额是否被视为违反5秒阈值？ 但是，对于大型企业帐户，异步地编译为CSV并在10分钟后通过电子邮件发送的完整帐户报表又如何呢？ 因此， 还要清楚等待时间与哪些操作无关。

好吧，您站点上的100位用户每隔10秒就会通过CDN投放一次静态图片，我敢打赌，您可以闭着眼睛来构建这样的系统。 100个用户同时在您的站点上对4K视频文件进行编码-您最好害怕。 真的很害怕

当考虑真正的并发时，事情从模棱两可变成无意义，例如将“ 100个并发用户”转换为“ 100个线程同时处理100个操作”。 假设每个这样的操作需要10秒钟来处理，那么系统的吞吐量为10 ops / sec。 如果现在将操作持续时间减少十倍，而每次操作仅需一秒钟，您的吞吐量便可以提高到100 ops / sec。 但是请注意，您没有满足“ 100个真正的并发用户”的要求，并且仅同时处理10个操作，因此没有达到要求。

需求应代替“并发用户”或任何其他类似术语，而应更清楚地表达某些用户的行为 ，并有可能将这些描述转变为负载测试，从而使您可以模拟必要的负载。

请注意，我不建议在这里测量吞吐量-实际应用程序通常是多功能的，并且在动态情况下使用。 这使得很难通过吞吐量（每小时操作）来表达性能目标。

但是，如果将特定应用程序设计为仅做一件事情，例如发票付款，那么具有类似于“ 1000发票/分钟”的吞吐量度量目标是一种具有可测量且特定目标的绝佳方法。

容量规划

您的应用程序应满足性能要求的数据量是多少？ 您是希望通过数据库中的10,000个帐户和10,000,000个事务来实现既定目标，还是希望系统通过1,000,000个帐户和1,000,000,000事务来满足这样的标准？ 清楚系统中存在的数据量 。

您对基础架构有哪些限制？ 您是否希望在$ 500 / mo AWS账单之内实现目标，还是可以疯狂地将解决方案部署在具有32核和几TB内存的高端设备上？ 知道这一点，可以帮助您了解基础结构的局限性。 因此，您应该从基础结构中指定约束。

依靠网络存在可以吗？ 在每次操作期间来回发送几个MB时，网络带宽是否可以接受？ 随着移动应用程序的广泛采用，您无法指望全能的4G出现，并且可能需要支持脱机操作并将流量压缩为千字节而不是兆字节。 因此，您需要了解应用程序将被部署的情况 。

结论

这篇文章中描述的方面列表绝不完整。 例如，当您开始将诸如可伸缩性或可用性之类的概念链接到组合时，您将面临一系列全新的要求。 但是我希望该职位能够满足您的意图，并且下次当您满足模糊定义的性能要求时，您会遇到一系列问题，以开始深入研究实际需求。

与企业所有者进行对话，以帮助发现可衡量的特定目标。 没有这些目标，您就没有实现或衡量结果的真正目标。

逐步执行该过程还可以使您解释相关费用。 如果您还记得的话，总是可以使一切变得更快。 问题是–它是否在经济上可行。 从企业所有者的角度来看，自然而然希望所有操作都超快。 只有在了解实现此目标的成本时，才能设定更切合实际的期望。

翻译自: https://www.javacodegeeks.com/2015/01/how-to-define-performance-requirements.html