繼前一篇《函數計算性能福利篇——系統冷啟動優化》，我們再來看看近期函數計算推出的?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?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 的編程模型實現業務層初始化邏輯:

#?-*-?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 的邏輯相同:

• 函數實例運行時，先執行 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 功能對業務層冷啟動的優化，又一次大大改善了函數計算在延時敏感場景下的表現！