用户指南性能优化实例(比快速更糟)(1)

“应用很慢,你可以确保它快速吗?”

上面的引用应该会让任何有经验的工程师感到脊背发凉。这里的“快速”的具体含义是什么?

除非你对“快速”部分有一个定义,否则你将永远陷入优化周期,因为每个应用都可以不断的被创建的更快一些。然而在现实生活中,性能并不是唯一一个需要我们完成的要求。所以为了能提供最大的价值,我们应该知道什么时候该停止性能优化。或者更重要的是,引导我们的性能目标应该是什么样的。

功能以外的需求

企业已经越来越好的表达软件的功能需求。但是考虑到功能需求以外的事情,比如可用性、兼容性或者性能,这个时候企业主的描述常常是相当于一片空白。而这片空白最常见的形式就是“确保它快”或“有没有更好的情况”,你对此会有类似于一下的处理方式:

  • 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的方案等, 知道这一点可以帮助你了解基础设施的限制。
  • 应用部署的环境是什么?比如网络带宽是多少,是否支持离线操作等。你需要了解你应用将要部署的环境需求。

结论

以上所列的描述是不完整的。举例来说,当涉及到可伸缩性和可用性时,你会面临一个全新的要求。本文旨在抛砖引玉,在你下次遇到模糊定义的性能需求时,你会有一系列的问题扩展这些模糊的需求。

与业务者的沟通有助于你发现可衡量的、特定的目标。从企业者来看,自然是希望所有操作的“超快速”。而为了实现这一目标,无外乎还是要归结到成本上。你说呢?(编译:陈明)

原文来自:DZone

,