本文的核心是用异质化服务器来实现serverless函数的keep-warm策略。主要贡献有以下
- Fourier Transform+一元二次多项式的请求时间预测
- 提出了一个utility score，按照得分级warmup，分数从高到低依次在high-end warmup、在low-end warmup、不warmup
基于openwhisk，开源: https://zenodo.org/record/5748667
值得学习的是，这篇文章通过在aws上租服务器来得到异质化服务器。
background
Observation
- 虽然low-end的执行效率比high-end低，但是low-end上的execution+warm start可能会比high-end上的execution+cold start时间短
- 对low-end和high-end使用不同的keep alive策略有助于降低service time和cost
Design
IceBreaker由两部分组成：
- Function Invocation Prediction Scheme (FIP)：预测invocation到来的时间
- Placement Decision Maker (PDM)：决定策略：warm在high-end上、warm在low-end上、不warm
Function Invocation Prediction Scheme
为什么之前的不行
- The inter-arrival time between two successive function invocations can keep varying, making probability-histogram-based inter-arrival time prediction schemes unsuitable for serverless.
- 没有预测concurrency
key design
一元二次方程拟合+傅立叶变换
- 一元二次方程处理没有周期的部分
- 傅立叶变化处理周期部分
\(FFT(f(t) - a*t^2 - b*t - c)\)
Placement Decision Maker
key design
utility score \(S_u = \frac{T_n + (1 - F_p) + (1 - I_s) + (1 - M_r)}{4}\)
- True negative：FIP预测的并发小了。增加Tn
- False positive：FIP预测的并发大了。
- Inter-server speedup：相比于low-end的服务器，在high-end服务器上的speedup
- Memory Footprint：内存越大，warmup越亏
如何放置？设定两个阈值，分别代表不需要warmup、在low-end上warmup、在high-end上warmup。用算出来的utility score去比
other considerations
- 如何避免utility score的ping-pong反复横跳？给一个窗口+阈值
- 具有大内存需求和低服务器加速率的函数被IceBreaker给予热启动的机会（没懂）
- 可扩展的