个人订阅号原创功能 日更300字 多久原创

来源：蜘蛛抓取(WebSpider) 时间：2017-08-07 08:57 标签： 个人订阅号原创功能

继前一篇《》我们再来看看近期函数计算推出的之后，带来的一波高能性能优化成果

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

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

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

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

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

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

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

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

 

 使用 initializer 的编程模型实现业务层初始化逻辑:
  • 函数实例运行时，先执行 init_handler 逻辑执行时间 30s，进荇业务层初始化；
  • 如果已经初始化那么就执行 handler 逻辑，执行时间 0.1s进行请求处理；如果没有初始化，那么先进行初始化逻辑再执行 handler 逻辑。 
 

 

 这里根据生产用户请求场景我们选择如下三种测试 case 来对比两种初始化函数实现的性能。
  • 函数 初始化 逻辑运行时间为 30s;
  • 函数代码包大小为 50MB; 
 

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

 

 该模式下用户的请求在一段时间内会持续增长。设计请求行为如下:
  • 每波请求的时间间隔为 35s 
 

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

 
 
 

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

 
 

 
 
 

 
 
 

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

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

 
 
 

 
 
 

 

 波峰burst模式是指用户请求比较平稳，但是会有突然的波峰流量场景设计请求行为如下：
  • 每波请求时间间隔 35s; 
 

 
 
 

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

 
 

 

 
 

 

 

 

 业务逻辑升级模式是指用户请求比较平稳但是用户函数会持续 UpdateFunction，变更业务逻辑进荇用户业务升级。设计请求行为如下：
  • 每波请求时间间隔 35s; 
 

 
 

 
 

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

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

 

 

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

 

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

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

我要回帖

更多关于 个人订阅号原创功能 的文章

 

随机推荐