繼前一篇《函數(shù)計算性能福利篇——系統(tǒng)冷啟動優(yōu)化》，我們再來看看近期函數(shù)計算推出的?Initializer 功能之后，帶來的一波高能性能優(yōu)化成果。

背景

函數(shù)計算是一個事件驅(qū)動的全托管 serverless 計算服務(wù)，用戶可以將業(yè)務(wù)實現(xiàn)成符合函數(shù)計算編程模型的函數(shù)，交付給平臺快速實現(xiàn)彈性高可用的云原生應(yīng)用。

用戶函數(shù)調(diào)用鏈路包括以下幾個階段：

• 系統(tǒng)為函數(shù)分配計算資源；

• 下載代碼；

• 啟動容器并加載函數(shù)代碼;

• 用戶函數(shù)內(nèi)部進(jìn)行初始化邏輯；

• 函數(shù)處理請求并將結(jié)果返回。

其中前三步是系統(tǒng)層面的冷啟動開銷，通過對調(diào)度以及各個環(huán)節(jié)的優(yōu)化，函數(shù)計算能做到負(fù)載快速增長時穩(wěn)定的延時，細(xì)節(jié)詳見?函數(shù)計算系統(tǒng)冷啟動優(yōu)化。
第4步是函數(shù)內(nèi)部初始化邏輯，屬于應(yīng)用業(yè)務(wù)層面的冷啟動開銷，例如深度學(xué)習(xí)場景下加載規(guī)格較大的模型、數(shù)據(jù)庫場景下連接池構(gòu)建、函數(shù)依賴庫加載等等。為了減小應(yīng)用層冷啟動對延時的影響，函數(shù)計算推出了 initializer 接口，便于用戶抽離業(yè)務(wù)初始化邏輯。這樣用戶就能將自身業(yè)務(wù)的初始化邏輯和請求處理邏輯分離，分別是實現(xiàn)在 initializer 接口和 handler 接口中，使得系統(tǒng)能識別用戶函數(shù)的初始化邏輯，從而在調(diào)度上做相應(yīng)的優(yōu)化。

Initializer 功能簡介

引入 initializer 接口的價值主要體現(xiàn)在如下幾個方面：

• 分離初始化邏輯和請求處理邏輯，程序邏輯更清晰，讓用戶更易寫出結(jié)構(gòu)良好，性能更優(yōu)的代碼；

• 用戶函數(shù)代碼更新時，系統(tǒng)能夠保證用戶函數(shù)的平滑升級，規(guī)避應(yīng)用層初始化冷啟動帶來的性能損耗。新的函數(shù)實例啟動后能夠自動執(zhí)行用戶的初始化邏輯，在初始化完成后再處理請求；

• 在應(yīng)用負(fù)載上升，需要增加更多函數(shù)實例時，系統(tǒng)能夠識別函數(shù)應(yīng)用層初始化的開銷，更精準(zhǔn)的計算資源伸縮的時機(jī)和所需的資源量，讓請求延時更加平穩(wěn)；

• 即使在用戶有持續(xù)的請求且不更新函數(shù)的情況下，F(xiàn)C系統(tǒng)仍然有可能將已有容器回收或更新，這時沒有平臺方（FC）的冷啟動，但是會有業(yè)務(wù)方冷啟動，Initializer可以最大限度減少這種情況；

具體的 Initializer 功能設(shè)計和使用指南，請參考官方?Initiliazer 介紹?。

初始化場景性能對比

上一節(jié)已經(jīng)簡單了概括了 Initializer 的功能，這里，我們具體展示一下初始化場景下 Initializer 帶來的巨大的性能提升效應(yīng)。

函數(shù)實現(xiàn)

初始化應(yīng)用場景，如果不使用 initializer，那么函數(shù)的主要實現(xiàn)方式應(yīng)該是 Global variable 方式，下面提供兩種實現(xiàn)方式的 demo ，僅供參考，下面的性能測試也是對比這兩種函數(shù)實現(xiàn)方式進(jìn)行了。

使用 global variables 實現(xiàn)業(yè)務(wù)層初始化邏輯:

#?-*-?coding:?utf-8?-*-import?timeimport?json

isInit?=?Falsedef?init_handler():
??time.sleep(30)??global?isInit
??isInit?=?Truedef?handler(event,?context):
??evt?=?json.loads(event)
??funcSleepTime?=?evt['funcSleepTime']??if?not?isInit:
???????init_handler()
??time.sleep(funcSleepTime)

使用 initializer 的編程模型實現(xiàn)業(yè)務(wù)層初始化邏輯:

#?-*-?coding:?utf-8?-*-import?timeimport?jsondef?init_handler(context):
??time.sleep(30)def?handler(event,?context):
??evt?=?json.loads(event)
??funcSleepTime?=?evt['funcSleepTime']
??time.sleep(funcSleepTime)

兩個 function 的邏輯相同:

• 函數(shù)實例運(yùn)行時，先執(zhí)行 init_handler 邏輯，執(zhí)行時間 30s，進(jìn)行業(yè)務(wù)層初始化；

• 如果已經(jīng)初始化，那么就執(zhí)行 handler 邏輯，執(zhí)行時間 0.1s，進(jìn)行請求處理；如果沒有初始化，那么先進(jìn)行初始化邏輯，再執(zhí)行 handler 邏輯。

場景對比

這里根據(jù)生產(chǎn)用戶請求場景，我們選擇如下三種測試 case 來對比兩種初始化函數(shù)實現(xiàn)的性能。

• 負(fù)載持續(xù)增加模式

• 波峰 burst 模式

• 業(yè)務(wù)邏輯升級模式

測試函數(shù)的特性如下:

• 函數(shù) handler 邏輯運(yùn)行時間為 100ms;

• 函數(shù) 初始化 邏輯運(yùn)行時間為 30s;

• 函數(shù)代碼包大小為 50MB;

• runtime 為 python2.7;

• Memory 為 3GB 。

這樣的函數(shù)，系統(tǒng)層冷啟動時間大約在 1s 左右，業(yè)務(wù)層冷啟動在 30s，而函數(shù)自身請求執(zhí)行時間為100-130ms。

負(fù)載持續(xù)增加模式

該模式下，用戶的請求在一段時間內(nèi)會持續(xù)增長。設(shè)計請求行為如下:

• 每波請求并發(fā)數(shù)翻倍遞增: 1, 2, 4, 8, 16, 32;

• 每波請求的時間間隔為 35s。

TPS情況如下，增長率為100%：

注意：忽略第一批請求的完全冷啟動的延時影響。

?不使用 initializer 實現(xiàn)的運(yùn)行結(jié)果：

從每波請求的請求延時可以看出，雖然系統(tǒng)層的調(diào)度能夠為后來的驟增的請求分配更多的函數(shù)實例，但是因為函數(shù)實例都沒有執(zhí)行過業(yè)務(wù)層的初始化邏輯，所以新的函數(shù)實例花費(fèi)了大量的執(zhí)行時間在初始化邏輯的執(zhí)行上，所以看到 99th latency 都大于 30s 。實際上，系統(tǒng)層的調(diào)度優(yōu)化在這樣長時間的初始化場景中并起不了作用。

使用 initializer 實現(xiàn)的運(yùn)行結(jié)果，可以看到使用 initializer 功能之后，請求增長率在 100% 的情況下不會再有函數(shù)實例執(zhí)行初始化邏輯，相對于優(yōu)化前，99th latency 下降了 30 倍以上。

波峰 burst 模式

波峰burst模式是指用戶請求比較平穩(wěn)，但是會有突然的波峰流量場景。設(shè)計請求行為如下：

• 每波請求時間間隔 35s;

• 每波平穩(wěn)請求數(shù) 2;

• burst 請求數(shù) 18;

• TPS請求如下，burst 流量猛增 9 倍:

注意：忽略第一批請求的完全冷啟動的延時影響。???

?不使用 initializer 實現(xiàn)的運(yùn)行結(jié)果：

?

使用 initializer 實現(xiàn)的運(yùn)行結(jié)果，對于 burst 的流量，基本能夠?qū)?latency 的增長控制在 函數(shù)處理邏輯 6 倍以內(nèi)，99th 的 latency 被優(yōu)化到原來的 2.9% 。

? 業(yè)務(wù)邏輯升級模式

業(yè)務(wù)邏輯升級模式是指用戶請求比較平穩(wěn)，但是用戶函數(shù)會持續(xù) UpdateFunction，變更業(yè)務(wù)邏輯，進(jìn)行用戶業(yè)務(wù)升級。設(shè)計請求行為如下：

• 每波請求時間間隔 35s;

• 每波平穩(wěn)請求數(shù) 2;

• 每 6 波請求進(jìn)行一次 UpdateFunction 操作;

TPS 如下:

?

注意：忽略第一批請求的完全冷啟動的延時影響。

?不使用 initializer 實現(xiàn)的運(yùn)行結(jié)果，這個時候請求又會重新執(zhí)行一次初始化邏輯，導(dǎo)致毛刺出現(xiàn)。

使用 initializer 實現(xiàn)的運(yùn)行結(jié)果，基本看出，UpdateFunction 操作對請求已經(jīng)沒有影響，業(yè)務(wù)層無感知。
?
?

總結(jié)

綜上數(shù)據(jù)分析，函數(shù)計算的 Initializer 功能極大的優(yōu)化了業(yè)務(wù)層冷啟動的毛刺影響：

• 在用戶請求存在明顯 burst 或者在以一定速率增長的情況下，能夠極大的緩解性能影響，如上，在負(fù)載持續(xù)增加模式和波峰模式場景下，請求平均 latency 僅僅增加 3 倍，99th latency 只增加了 5 倍，99th latency 僅為優(yōu)化前的 2.9% ，整整下降了 33 倍之多。

• 在用戶有持續(xù)的請求且不更新函數(shù)的情況下，優(yōu)化之后更新函數(shù)，業(yè)務(wù)層能夠做到無感知，平滑熱升級。

Initializer 功能對業(yè)務(wù)層冷啟動的優(yōu)化，又一次大大改善了函數(shù)計算在延時敏感場景下的表現(xiàn)！