函数计算性能福利篇(二) —— 业务冷启动优化

2018-11-06 3030

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介：

继前一篇《函数计算性能福利篇——系统冷启动优化》，我们再来看看近期函数计算推出的 Initializer 功能之后，带来的一波高能性能优化成果。

背景

函数计算是一个事件驱动的全托管 serverless 计算服务，用户可以将业务实现成符合函数计算编程模型的函数，交付给平台快速实现弹性高可用的云原生应用。

用户函数调用链路包括以下几个阶段：

系统为函数分配计算资源；
下载代码；
启动容器并加载函数代码;
用户函数内部进行初始化逻辑；
函数处理请求并将结果返回。

其中前三步是系统层面的冷启动开销，通过对调度以及各个环节的优化，函数计算能做到负载快速增长时稳定的延时，细节详见函数计算系统冷启动优化。
第4步是函数内部初始化逻辑，属于应用业务层面的冷启动开销，例如深度学习场景下加载规格较大的模型、数据库场景下连接池构建、函数依赖库加载等等。为了减小应用层冷启动对延时的影响，函数计算推出了 initializer 接口，便于用户抽离业务初始化逻辑。这样用户就能将自身业务的初始化逻辑和请求处理逻辑分离，分别是实现在 initializer 接口和 handler 接口中，使得系统能识别用户函数的初始化逻辑，从而在调度上做相应的优化。

Initializer 功能简介

引入 initializer 接口的价值主要体现在如下几个方面：

分离初始化逻辑和请求处理逻辑，程序逻辑更清晰，让用户更易写出结构良好，性能更优的代码；
用户函数代码更新时，系统能够保证用户函数的平滑升级，规避应用层初始化冷启动带来的性能损耗。新的函数实例启动后能够自动执行用户的初始化逻辑，在初始化完成后再处理请求；
在应用负载上升，需要增加更多函数实例时，系统能够识别函数应用层初始化的开销，更精准的计算资源伸缩的时机和所需的资源量，让请求延时更加平稳；
即使在用户有持续的请求且不更新函数的情况下，FC系统仍然有可能将已有容器回收或更新，这时没有平台方（FC）的冷启动，但是会有业务方冷启动，Initializer可以最大限度减少这种情况；

具体的 Initializer 功能设计和使用指南，请参考官方 Initiliazer 介绍。

初始化场景性能对比

上一节已经简单了概括了 Initializer 的功能，这里，我们具体展示一下初始化场景下 Initializer 带来的巨大的性能提升效应。

函数实现

初始化应用场景，如果不使用 initializer，那么函数的主要实现方式应该是 Global variable 方式，下面提供两种实现方式的 demo ，仅供参考，下面的性能测试也是对比这两种函数实现方式进行了。

使用 global variables 实现业务层初始化逻辑:

# -*- coding: utf-8 -*-
import time
import json

isInit = False
def init_handler():
  time.sleep(30)
  global isInit
  isInit = True

def handler(event, context):
  evt = json.loads(event)
  funcSleepTime = evt['funcSleepTime']
  if not isInit:
       init_handler()
  time.sleep(funcSleepTime)

使用 initializer 的编程模型实现业务层初始化逻辑:

# -*- coding: utf-8 -*-
import time
import json

def init_handler(context):
  time.sleep(30)

def handler(event, context):
  evt = json.loads(event)
  funcSleepTime = evt['funcSleepTime']
  time.sleep(funcSleepTime)

两个 function 的逻辑相同:

函数实例运行时，先执行 init_handler 逻辑，执行时间 30s，进行业务层初始化；
如果已经初始化，那么就执行 handler 逻辑，执行时间 0.1s，进行请求处理；如果没有初始化，那么先进行初始化逻辑，再执行 handler 逻辑。

场景对比

这里根据生产用户请求场景，我们选择如下三种测试 case 来对比两种初始化函数实现的性能。

负载持续增加模式
波峰 burst 模式
业务逻辑升级模式

测试函数的特性如下:

函数 handler 逻辑运行时间为 100ms;
函数初始化逻辑运行时间为 30s;
函数代码包大小为 50MB;
runtime 为 python2.7;
Memory 为 3GB 。

这样的函数，系统层冷启动时间大约在 1s 左右，业务层冷启动在 30s，而函数自身请求执行时间为100-130ms。

负载持续增加模式

该模式下，用户的请求在一段时间内会持续增长。设计请求行为如下:

每波请求并发数翻倍递增: 1, 2, 4, 8, 16, 32;
每波请求的时间间隔为 35s。

TPS情况如下，增长率为100%：

注意：忽略第一批请求的完全冷启动的延时影响。

不使用 initializer 实现的运行结果：

从每波请求的请求延时可以看出，虽然系统层的调度能够为后来的骤增的请求分配更多的函数实例，但是因为函数实例都没有执行过业务层的初始化逻辑，所以新的函数实例花费了大量的执行时间在初始化逻辑的执行上，所以看到 99th latency 都大于 30s 。实际上，系统层的调度优化在这样长时间的初始化场景中并起不了作用。

使用 initializer 实现的运行结果，可以看到使用 initializer 功能之后，请求增长率在 100% 的情况下不会再有函数实例执行初始化逻辑，相对于优化前，99th latency 下降了 30 倍以上。

波峰 burst 模式

波峰burst模式是指用户请求比较平稳，但是会有突然的波峰流量场景。设计请求行为如下：

每波请求时间间隔 35s;
每波平稳请求数 2;
burst 请求数 18;
TPS请求如下，burst 流量猛增 9 倍:

注意：忽略第一批请求的完全冷启动的延时影响。

不使用 initializer 实现的运行结果：

使用 initializer 实现的运行结果，对于 burst 的流量，基本能够将 latency 的增长控制在函数处理逻辑 6 倍以内，99th 的 latency 被优化到原来的 2.9% 。

业务逻辑升级模式

业务逻辑升级模式是指用户请求比较平稳，但是用户函数会持续 UpdateFunction，变更业务逻辑，进行用户业务升级。设计请求行为如下：

每波请求时间间隔 35s;
每波平稳请求数 2;
每 6 波请求进行一次 UpdateFunction 操作;

TPS 如下:

注意：忽略第一批请求的完全冷启动的延时影响。

不使用 initializer 实现的运行结果，这个时候请求又会重新执行一次初始化逻辑，导致毛刺出现。

使用 initializer 实现的运行结果，基本看出，UpdateFunction 操作对请求已经没有影响，业务层无感知。

总结

综上数据分析，函数计算的 Initializer 功能极大的优化了业务层冷启动的毛刺影响：

在用户请求存在明显 burst 或者在以一定速率增长的情况下，能够极大的缓解性能影响，如上，在负载持续增加模式和波峰模式场景下，请求平均 latency 仅仅增加 3 倍，99th latency 只增加了 5 倍，99th latency 仅为优化前的 2.9% ，整整下降了 33 倍之多。
在用户有持续的请求且不更新函数的情况下，优化之后更新函数，业务层能够做到无感知，平滑热升级。

Initializer 功能对业务层冷启动的优化，又一次大大改善了函数计算在延时敏感场景下的表现！

函数计算性能福利篇(二) —— 业务冷启动优化

背景

Initializer 功能简介

初始化场景性能对比

函数实现