通过Responsive Time Law理解性能拐点(Knee Of The Curve)

Last update: 20180703

性能分析中除了Little’s law之外 Responsive time law(以下简称为RTL) 也是常用到的公式。RTL的最大贡献是量化了资源使用率与响应时间间的关系。性能分析领域中有个著名的点,叫”性能拐点(Knee of the cureve)”,本文讨论我关于这个点的几个思考。通过RTL公式可以看到当资源使用率超过某个点时响应时间会暴涨,这会引申出三个思考点:

  • RTL公式究竟长成什么样?
  • 性能拐点的定义是什么?
  • 性能拐点的应用

RTL公式究竟长成什么样?

RTL公式是通过Erlang C推导而来的,而Erlang C是用于描述排队论中任务被阻塞等待的概率。RTL公式目前只适用于符合M/M/c排队模型的队列。M/M/c是什么意思呢?他是Kendal notaion,具体意义为:

  • M:请求到达的时间间隔呈现为指数分布,平均到达请求数量呈泊松分布。
  • M:服务时间分布呈指数分布。
  • c:服务数量 1为队列中只有一个server,2为有两个server。

当队列满足M/M/c模型时计算响应时间公式为:

响应时间 = 队列等待时间 + 服务时间
函数参数 c为server数量,p为资源使用率。

使用Erlang C函数展开队列等待时间为:

这里给出的是最终的结果,使用ErlangC推导整个等待队列时间比较复杂故此省略了。
Erlang在1917年通过泊松概率分布推导出了Erlang C公式,用于量化当时电信业务。需要注意的是使用Erlang C计算RTL时服务请求与服务处理时间需要满足各自的概率分布,也就是指数分布与泊松分布,而且要求每个请求间是相互独立,互不依赖。

另外值得一提的是网上还有一种简化版的RTL公式:

m 为服务数量,与上一个公式中的c相同。

这个公式在m满足<=2时与使用Erlang C的版本在结果上是一致的,但是当m超过2时精度没有比使用Erlang版本的高。简化版公式的意义在于可以通过心算的方式大致估摸出结果,再者就是减少计算量。但为了准确性,在这里还是推荐Erlang版本(毕竟这点计算量在现代处理器上是不叫事儿了)。

当c = 8,绿色为Erlang版本,紫色为简化版,从肉眼上可以看到简化版比较消极一些。从严谨的意义来说,这会使我们误认为系统性能相比实际情况好一些。

性能拐点的定义是什么?

从上面曲线中可以看出越是接近1,响应时间(y轴)上升坡度越陡峭。曲线中存在某个点(资源使用率),超过这个点时响应时间会暴涨,我们称呼他为Knee of the curve。那Knee的具体定义是什么样的呢?我查阅相关资料时发现有多种不同的定义;

  1. 使用率达到75%的点为Knee。
  2. 有一条直线,穿过原点并与曲线交接的点为Knee。
  3. 响应时间为服务时间的2倍的点为Knee。

可以明显的看出定义1是不够准确的,因为从曲线中看出随着server的数量(c)的增大曲线的陡峭是越往后移的。如果设75%为Knee点,在多Server的队列中会浪费硬件资源。定义2是从数学角度得出的Knee,这在实际业务中的实际应用效果有待观察。定义3是根据业务的需求得出的定义,比如有些业务严格要求响应时间不能超过服务时间的两倍,但有些又可以容忍到三倍。

所以总结来看,RTL曲线虽然可以提示我们随着使用量的增大,响应时间以类似曲棍球杆的形状陡峭增长,但具体从哪个Knee点开始性能变差且不可接受是没有标准答案的。因为,它依赖具体的业务,依赖你的客户容忍度,依赖你的硬件成本,依赖你的软件架构。

读者可以通过点此曲线来观察下不同的c与S变量下曲线的变化程度。

性能拐点的应用

既然无法得出具体的Knee点定义,那我们怎么利用好它呢?通过以下两个角度来思考

  • 资源使用率
  • 响应时间的容忍值

资源使用率的思考:

  • 业务是批处理时:可以100%资源使用,因为此时尽可能榨干硬件性能是有利于资源利用。
  • 业务是与用户的交互场景时:资源率使用不宜超过Knee,当然这时根据业务需要定义Knee点。
  • 业务是批处理与用户交互场景的混合型时:
    • 区分出前台与后台任务
    • 通过Resource Control方法设置前后台各自的资源使用率上限 e.g. cpuset, cgroup
    • 当用户交互时提高前台资源的预留比例并限制后台任务请求。

响应时间的容忍值的思考:

写在最后

  • 概率统计是一门非常有意思的学科,将其利用到性能数据分析上是未来学习方向之一。
  • 除了数据可视化之外,函数可视化也能提供不少线索。本文中使用的曲线由desmos.com生成,推荐给各位。
  • 性能分析时不要相信自己的直觉,一定要通过[数据收集 -> 建模 -> 量化结果]的方法来验证效果。

Reference