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

Posted on

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