面向HPC的函數計算冷啟動優(yōu)化 *

李 哲，譚郁松，李 寶，余 杰

(國防科技大學計算機學院,湖南 長沙 410073)

1 引言

高性能計算問題的解決往往需要用到大量的計算資源，包括足夠的內存、足夠的存儲空間以及為了提升并行計算效率的大量CPU。利用以虛擬機為節(jié)點的傳統(tǒng)云計算架構，租用大量的云計算資源是一個不錯的解決方案[1]。然而，在傳統(tǒng)云計算的架構模式下，用戶不僅需要針對計算任務做出復雜的分布式設計，同時也需要租用大量的額外計算資源來應對高性能計算問題中可能出現(xiàn)的峰值現(xiàn)象[2]。在實際的任務執(zhí)行過程中，還需要考慮到節(jié)點的故障與恢復等問題。另外，在整個高性能任務執(zhí)行過程中，申請的云計算資源并不會一直處于滿負載或者高負載的狀態(tài)，導致被用來應對峰值效應的很大一部分資源都出現(xiàn)了浪費現(xiàn)象。

函數計算是近幾年誕生的一種全新的云計算范型，是無服務器計算的一種服務模式[3]。與傳統(tǒng)云計算相比，用戶在函數計算平臺上不再需要關心服務器的維護和一些分布式特性的管理，只需要通過函數計算平臺提供的相關接口將代碼上傳，并設定好預期使用資源和運行時長等參數，就可以將其當作一個完整的分布式應用運行。圖1給出了一個典型的函數計算平臺架構圖。每一個云函數是一個基本的計算單元模型，包括了待運行的代碼包、一系列參數設置以及相關的配置文件等。每個云函數都可以獨立執(zhí)行自己的業(yè)務邏輯，也可以通過函數調用的方式與其他云函數進行交互。通常一個計算任務會由不同的事件觸發(fā)而執(zhí)行，這些事件可以由不同的事件觸發(fā)器(HTTP觸發(fā)器、定時觸發(fā)器和對象存儲服務觸發(fā)器等)進行捕獲。

Figure 1 Architecture of FaaS圖1 函數計算平臺架構圖

當函數計算平臺收到一個請求時，平臺會先定位到相關的云函數，然后會根據云函數提供的配置信息(業(yè)務代碼、資源限定參數等)提供一個能夠處理該請求的容器。容器作為函數計算最基本的計算實例，具有獨立的計算資源和運行空間，并且裝載了對應云函數所必要的運行環(huán)境和相應的業(yè)務代碼。在處理高性能并發(fā)請求的時候，函數平臺能夠根據請求數量自動地進行擴容，而不需要用戶進行管理。同時對單個容器而言，當前容器最大允許使用的內存由用戶自行設定。這種快速自動擴容的機制恰好能夠很好地用于高性能計算中的并行任務[4]，而且不會造成大量的計算資源浪費。這種由平臺隱性提供的備用資源措施雖然能夠節(jié)省很大一筆費用，但也帶來了一個函數計算平臺上存在的潛在問題——冷啟動延遲問題。如上文所述，一個對云函數的請求是由平臺所提供的函數容器進行處理的，如果這個容器是之前剛使用過的(通常一個容器被使用完能夠存活15～20 min[5])，那么幾乎不用額外的啟動耗時就可以接著處理新來的請求。但是，如果該云函數一開始就不存在相關函數容器實例，平臺就需要為其新創(chuàng)建一個，而在平臺收到請求到完成請求處理的這段時間中，需要花費額外的時間來進行容器初始化、運行環(huán)境初始化和代碼下載等準備工作。這部分任務執(zhí)行之外的額外耗時被稱作冷啟動延遲。盡管一次冷啟動延遲最多可能僅達到幾百毫秒，但考慮到高性能計算應用存在很大的并發(fā)量，這個問題就會被嚴重放大。

針對上述問題，本文結合阿里云提出的快速擴容機制[6]，提出了一種通過預熱方式來降低冷啟動延遲的方法，該方法能夠有效地降低函數計算平臺在執(zhí)行高性能計算這一類任務時產生的冷啟動延遲。本文第2節(jié)介紹有關高性能計算任務和函數計算問題的相關工作；第3節(jié)和第4節(jié)將對提出的方法進行定義并通過一個高性能計算問題的實驗來說明其優(yōu)化效果；最后對所完成的工作做一個簡短的總結并給出今后的工作計劃。

2 相關工作

Chung團隊[6]在很早就做過高性能計算與容器虛擬化技術結合的研究工作。他們在容器(docker)上運行最常用的高性能計算測試工具HPL(High Performance Linpack)[7]和 Graph500[8]，用容器化的方式來執(zhí)行高性能計算任務。同時他們比較了在虛擬機和容器2種模式下高性能計算任務的執(zhí)行性能，發(fā)現(xiàn)在容器上的運行效果遠遠好于在虛擬機上的效果。而Spillner團隊[9]則進一步將高性能計算問題遷移到了函數計算平臺來處理。Josef團隊設計了4個典型的高性能計算問題：斐波那契數列、人臉檢測、密碼破譯和天氣預測。這4個問題的共同特點是都是計算密集型，而計算密集型任務恰好能夠很好地適應函數計算這種計算模式[9,10]。

Malla等人[11]通過實驗詳細對比了高性能計算任務在函數計算平臺上和傳統(tǒng)云計算平臺上執(zhí)行的各項結果，包括執(zhí)行的速度、所需的時間和租用的經濟成本等。作者以蛋白質序列匹配算法作為測試任務，分別運行在谷歌的函數計算平臺(GCF)上和傳統(tǒng)的基礎設施平臺(GCE)上。他們發(fā)現(xiàn)盡管GCF的性能會產生一定的波動，但在相同的性能下，使用GCF會比GCE更加便宜。另一方面，這2種執(zhí)行模式都會產生前期的任務準備耗時，但在GCF上表現(xiàn)得更為明顯。這是因為在任務準備階段，平臺需要在短時間內生成大量容器實例，從而導致冷啟動延遲較長。

針對函數計算平臺上存在的冷啟動延遲這一問題，Lin等人[12]提出利用容器池來對使用過的容器進行保存。他們利用已有的開源函數計算框架Knative[13]進行改進，通過在框架中加入容器池請求的步驟達到優(yōu)化的目的。這種優(yōu)化方式在容器實例較少的情況下的確能夠有不錯的表現(xiàn)，但如果處理高并行度的計算任務，其劣勢就很明顯，因為不可能每次都提前預存好上百個容器實例。為了使函數計算平臺更好地用于解決高性能計算這種短期內并發(fā)度較高的計算問題，阿里云提出了一種容器的動態(tài)加載技術，能夠在短時間內快速復制出大量相同的容器實例，其實驗結果顯示能夠達到秒級啟動一萬個容器的效果[14]。

上述工作已經證明高性能計算能夠很好地和函數計算結合，與此同時函數計算平臺在處理該類問題時也確實存在一定的優(yōu)化空間[15,16]。上文給出的優(yōu)化策略，很多都是從架構的角度重新設計一個新的函數計算平臺，這對于一般的云計算開發(fā)者來說無疑是復雜且耗時的。因此，本文將基于阿里云的公有云函數計算平臺，結合阿里云平臺自身的快速擴容策略，從用戶使用的角度出發(fā)，提出一種結合時間序列分析技術的預熱方法，來有效降低高性能計算問題在函數計算上的冷啟動延遲。

3 冷啟動分析

實際上高性能計算在函數計算平臺上的冷啟動現(xiàn)象已經在一些研究工作中被觀測到過[17,18]。為了更清晰地展示觀測到的冷啟動延遲，本節(jié)設計了針對不同編程語言的實驗，通過調整計算量大小來觀察冷啟動延遲是否會發(fā)生明顯的變化。觀測實驗部署在國內2個知名的函數計算平臺上，分別為阿里云的FC(Function Compute)[19]和騰訊云的SCF(Serverless Cloud Function)[20]。

第1個實驗不包含復雜的邏輯，僅執(zhí)行一句“hello world”的輸出，目的是測試冷啟動延遲在函數計算平臺上的存在性。在模擬冷啟動時，只需新建一個云函數，那么第1次請求就符合冷啟動的條件——不存在該云函數的任何容器實例；對于熱啟動，只需執(zhí)行完一次請求后接著執(zhí)行，就能夠滿足。本文對FC和SCF上支持的語言都進行了測試，如表1所示，短橫線“-”表示FC不支持Go語言。從表1中可以看出，幾乎所有的實驗中都存在明顯的冷啟動延遲現(xiàn)象。另外發(fā)現(xiàn)，在測試腳本語言Python時，冷啟動和熱啟動運行時長幾乎沒有差別，這很可能是因為平臺事先準備好了相關的容器，而腳本語言的環(huán)境并不需要任何的預加載。與之相反的是Java，可以很明顯地觀察到其在冷啟動下的執(zhí)行時長要遠遠超過在熱啟動下的執(zhí)行時長。這是因為即使平臺預先準備好了容器，但Java這種跨平臺語言運行之前需要包含JVM的啟動過程以及類的加載過程，因此可以很明顯地觀測到。在接下來的實驗中，我們也會選取Java這種易觀察到冷啟動現(xiàn)象的語言來進行實驗。

Table 1 Simple task executed on SCF and FC in the way of cold start and warm start

在第1個實驗中，觀測到了冷啟動延遲在函數計算平臺上的存在，相對于其他編程語言而言，Java的冷啟動延遲最為明顯，所以接下來的第2個實驗利用Java這種冷啟動延遲明顯的語言進一步分析冷啟動延遲是否受到計算量、內存設定大小以及一些其他因素的影響。實驗環(huán)境為：JDK 1.8，Maven 3.6.1以及阿里云的FC平臺。這個實驗利用FC在不同內存設定下計算不同計算量的遞歸版本的斐波那契數列，然后每種樣例分別在冷啟動和熱啟動情況下測試10次，觀察對照2種啟動模式下的執(zhí)行情況。

計算任務大小實驗結果如圖2所示。圖2a描述的是運行時長與內存大小之間的關系，在該實驗中，計算量是保持一致的(即斐波那契數列的計算長度是一致的)。盡管當內存被設定為256 MB時，運行時長會處于最低，但仍然遠遠高于熱啟動的運行時長。如圖2a所示，在不同的內存設定中，2種啟動模式下的平均運行時長分別為108 ms和13 ms，其差值大約為100 ms左右。圖2b展示了計算量大小與在不同啟動模式下的延遲關系，從中可以看到，盡管在冷啟動和熱啟動2種情況下，運行時長都會呈指數增長，但是二者的差值仍然保持在100 ms左右。這表明冷啟動延遲是一個趨于穩(wěn)定的值。

Figure 2 Different cases of Fabonaci sequence test圖2 不同參數設定下的斐波那契數列運行結果

最后在第3個實驗中觀察了FC本身采用的快速擴容機制。在計算斐波那契數列的實驗中，利用阿里云FC提供的SDK進行了并發(fā)請求的測試。每次測試中，在客戶端同時向同一個云函數發(fā)送10條執(zhí)行請求，并觀察其平均執(zhí)行時長。其中斐波那契數列的計算量設定為遞歸計算第35項，同時將云函數的最大允許使用內存設定為512 MB。如表2所示，當一個云函數存在1個容器實例時，意味著1個熱啟動處理和9個冷啟動處理，那么10條請求的平均處理時長并不會太長，僅僅比單次熱啟動延遲多17 ms；而當不存在容器實例時，意味著10條請求都是冷啟動，此時平均處理時長不僅僅高于單次熱啟動時長，甚至比單次冷啟動時長還要高出將近30%。這個實驗結果說明，阿里云能夠利用一個已有的完整容器——阿里云容器團隊提出的DADI加速器[14]進行快速擴容。

Table 2 Concurrent requests test 表2 并發(fā)請求實驗 ms

一般而言，一個完整的容器啟動鏡像往往有上百MB甚至達到GB級，如果每次將已有的鏡像完整加載，那么耗時是很高的。阿里云提出的DADI加速器避免了傳統(tǒng)容器“下載鏡像 > 解壓鏡像 > 啟動容器”的啟動步驟，容器的啟動耗時以及擴容時間大大縮短，這其中包括3點優(yōu)化：(1)鏡像格式優(yōu)化：DADI團隊設計了一種新型的鏡像模式，無需下載和解壓全部的完整鏡像即可直接訪問；(2)按需P2P數據讀?。篋ADI利用樹形P2P網絡對數據進行分發(fā)，即少數P2P根節(jié)點從Registry獲取，其他節(jié)點(宿主機)之間可相互傳輸數據，利用已有容器快速分發(fā)數據到所有節(jié)點從而進行擴容；(3)高效的壓縮算法：DADI提供了一種新型的壓縮文件格式，可按需單獨解壓用戶實際訪問的數據，且解壓時間開銷可忽略不計[14]。

4 解決方案

函數計算平臺最大的一個特點是不會暴露給用戶任何能夠直接操控容器的接口，因此站在用戶的使用角度只能夠通過調用接口進行優(yōu)化。本文提出的策略就是提前預測請求到來的時間，然后觸發(fā)該云函數產生一個完整的容器實例，讓之后到來的請求以熱啟動的方式運行。

在本節(jié)首先對要用到的開源預測工具Prophet[21]進行測試，接著采用本文提出的預熱方式，分別對密碼破譯以及多容器協(xié)同求π值等場景進行實驗。其中的對照實驗包括熱啟動后的執(zhí)行效果和冷啟動后的執(zhí)行效果。在冷啟動的實驗中，為了保證每一次調用都是冷啟動調用，實驗在每次測試時重新創(chuàng)建新的云函數，同時在運行結束后，將該云函數刪除，這樣就可以保證下一次不會使用到先前殘留的熱容器實例。

4.1 預測請求時間

Prophet是Facebook提供的一款開源的時間序列分析工具，可以廣泛應用于現(xiàn)實生活中的各類時間序列分析問題。Prophet認為任意一個時間序列，都由以下幾個部份組合而成：

ypredict(t)=g(t)+s(t)+h(t)+p(t)+ε

(1)

其中,t表示待預測的時間；ypredict(t)表示預測值，g(t)表示數據的大趨勢(比如整體的預測值呈上升趨勢)；周期項s(t)表示周期性的變化趨勢，即s(t)的值每隔一個周期就會重復出現(xiàn)相同的變化趨勢，周期內的單位時間間隔由數據本身決定(比如每分鐘，每小時，本文實驗的單位時間間隔為每5分鐘)，而每個周期內包含的總的時間間隔是相同的；h(t)表示特殊事件(比如節(jié)假日)；p(t)表示外部因素的影響(比如天氣因素、環(huán)境因素)；ε表示噪聲。

本文利用Prophet預測請求時間，本文所涉及到的請求日志數據是每5分鐘一次請求的時間序列，不考慮復雜的特殊性因素，這類時間序列存在以每天為單位的周期性，同時并不具備長期變化的大趨勢。在這種情形下，只考慮周期項s(t)即可，s(t)可表示為：

(2)

其中，P表示頻率，在本文所考慮的情形下，時間序列為每5分鐘一次，周期為每天，因此有P=24*60/5=288。

s(t)可表示為2個向量相乘的形式：

s(t)=X(t)·β

(3)

其中,

1≤n≤N

(4)

β=[a1,b1,a2,b2,…,aN,bN]T

(5)

關于N的取值，通常Prophet會根據周期大小給定一個默認值。可以看到的是，N的取值越大，考慮的分量因素就越多，預測得更加精確但是更容易導致過擬合。s(t)的整個預測過程就是通過已有的時間序列擬合出參數an和bn(1≤n≤N)，然后再利用擬合出的參數預測相應的時間值，最終得到預測結果。

由于并不能獲取到FC的用戶日志信息，本文利用Prophet在Github上提供的測試數據集進行了測試。該數據集包含18 000條時間序列，是一個連續(xù)2個月左右、間隔5分鐘的時間序列數據集，精度都為秒級，同時每條序列后都對應一個y值，代表5分鐘內的請求數量。為了模擬函數計算的請求，本文根據y的范圍取中間的值作為一個閾值，超過閾值的y設置為1，表示該時間點的未來5分鐘內存在一個即將到來的請求；低于閾值設置為0，表示未來5分鐘沒有請求到來。實際上1可以表示一條請求或多條請求，因為在實驗設計中，無論是一條請求或者是多條請求，只要是在5分鐘的時間段內，實際上都只會對云函數進行一次預熱處理。另外，考慮到容器的存活時間具有延續(xù)性——每次處理完新的請求，都至少能再存活15分鐘左右，因此本文的實驗策略就是比較預測時間點和實際時間點的請求處理狀態(tài)是冷啟動處理還是熱啟動處理即可。比如一段連續(xù)的預測值為:1(第5分鐘有請求)，0(第10分鐘無請求)，0(第15分鐘無請求)。而實際值為：1(第5分鐘有請求)，1(第10分鐘有請求)，1(第15分鐘有請求)。由于容器存活時間具有延續(xù)性，那么預測點的狀態(tài)就為：第5、10、15分鐘該容器都是處于熱狀態(tài)的，剛好能以熱啟動的方式處理實際到來的請求。也就是說，只要容器狀態(tài)為熱啟動狀態(tài)，那么無論是否有請求到來，容器都保持熱狀態(tài)。基于此得出的平均預測準確率大約為86%，說明該預測工具在這種情況下的預測準確率還是相當不錯的。

4.2 單容器實例破譯密碼

本節(jié)首先對單容器運行案例進行測試，測試用例是通過云函數暴力破解一個5位數的隨機密碼。該隨機密碼由數字0～9以及所有的大小寫字母組成，隨機初始種子可由用戶指定。實驗測試一共分為3個部份：冷啟動測試、熱啟動測試和預熱后測試。

在函數的設計上，實驗中的該云函數會被綁定一個HTTP觸發(fā)器，該觸發(fā)器可以捕獲任意訪問該云函數的HTTP請求。通過對HTTP請求參數的解析，云函數可以決定如何進行下一步操作。在每次請求中會加入2個參數，分別是execute和seed。只有當execute的值為true時，云函數才會執(zhí)行密碼破譯的任務，同時根據給定的種子值seed,去生成一個隨機的5位密碼；而當execute被指定為false時，則不會執(zhí)行任何計算任務，直接退出。這樣做的目的是為了對該云函數的容器進行一個最快的預熱處理，使預測到的請求能夠熱啟動執(zhí)行的同時盡可能地減少不必要的計算成本。

在冷啟動測試的過程中，每次利用相同的執(zhí)行代碼創(chuàng)建一個新的云函數，以此來保證每個容器不會被復用。另外，將execute參數直接設定為true，使云函數一收到請求就直接開始執(zhí)行，同時執(zhí)行完畢后刪除云函數及其綁定的觸發(fā)器。在熱啟動實驗中，首先創(chuàng)建一個云函數，順序執(zhí)行多次請求(得到響應結果后再發(fā)出下一次請求，同時請求的參數execute設定為true)后，再開始進行測試。這樣就可以保證每次測試使用的都是同一個云函數容器實例。預熱實驗的執(zhí)行過程則分為多個步驟進行。因為該方法本身就是為了優(yōu)化冷啟動問題，所以仍然需要像冷啟動測試過程一樣，每次都創(chuàng)建新的云函數和觸發(fā)器。在處理請求第一步首先對云函數進行預熱處理，將execute參數設置為false，并發(fā)送一條請求；當收到響應信息后，再將execute參數設定為true，并給seed賦值，令之前產生的容器實例執(zhí)行密碼破譯任務。每種情形都進行10次測試，而為了保證計算時長的一致性，設定的seed也都一致，最終的測試結果如表3所示。

Table 3 Single task request test 表3 單任務請求實驗 ms

在預期上，單容器實例預熱啟動的2步總耗時應該和冷啟動耗時大致相同。一次完整的預熱啟動過程包括信號預熱和執(zhí)行請求2個部分，其中預熱時長為183 ms，執(zhí)行時長為973 ms。表3所示的運行結果基本上與預期值一致，即預熱后的執(zhí)行能夠至少減少183 ms的啟動延遲。由于單步冷啟動執(zhí)行被分為2步，這個并不連續(xù)的過程會導致預熱啟動的總耗時略微高于單次冷啟動的執(zhí)行時長，但對用戶而言，增加的3 ms和減少的183 ms相比幾乎可以忽略不計。另外讀者可能會發(fā)現(xiàn)，即使預熱后執(zhí)行，仍然比熱啟動執(zhí)行時長略高，這是因為阿里云采用了動態(tài)鏡像加載的優(yōu)化策略，在每次執(zhí)行時只加載完整鏡像中運行所必須的一小部分文件。而熱啟動實驗是在單個容器執(zhí)行了幾次之后才開始進行的，因此容器內所需的代碼運行環(huán)境已經加載完全，運行時長會比預熱后的第一次運行時長更短。

4.3 多容器實例協(xié)同計算π值

本節(jié)利用阿里云的快速擴容機制對多容器實例協(xié)同處理問題進行測試。與4.2節(jié)實驗一樣，仍然為每一個云函數綁定HTTP觸發(fā)器，同時通過HTTP請求傳參的方式告知云函數進行預熱處理還是執(zhí)行任務。為了模擬高性能計算在函數計算平臺上的執(zhí)行過程，本節(jié)設計了一個多容器實例計算泰勒展開式的實驗。該實驗利用多個容器實例協(xié)同計算π的泰勒展開前1億項來近似逼近π,如公式(6)所示：

(6)

本節(jié)設計了2個云函數來解決這個問題，如圖3所示。執(zhí)行過程分為3步：首先從客戶端向counter云函數發(fā)送執(zhí)行請求，請求中會包含3個參數：execute、n和N，分別代表是否執(zhí)行計算任務、執(zhí)行計算任務所需計算實例的個數(即圖3中的Computing Unit函數)和泰勒展開式的項數；接著counter根據接收的參數在同一時刻向Computing Unit函數通過線程池發(fā)送n條請求，并在每條請求上分別設定好對應實例所需計算的泰勒展開項式的位置(比如第i條請求計算泰勒展開式的第j到第k項)，同時由counter中的每一個異步請求結果類(Java中為FutureTask類)對請求結果進行維護；當所有的請求都發(fā)送出去后，counter實例則會通過輪詢的方法將所有Computing Unit實例結果進行匯總，并由counter實例將結果返回給客戶端。本節(jié)n設置為10，N設置為100 000 000。

Figure 3 Architecture of π computing task圖3 多容器計算π值架構圖

與4.2節(jié)一樣，實驗分別對冷啟動情形、熱啟動情形和預熱后情形進行測試。與4.2節(jié)實驗不同的是，本節(jié)實驗涉及到了二次請求，即客戶端先請求counter，counter再請求Computing Unit。在冷啟動和預熱實驗測試中，為了保證每次請求都產生新的容器，仍然采用“創(chuàng)建—調用—刪除”云函數的操作方式。另一方面，如第3節(jié)測試結果顯示，單個Java運行環(huán)境至少需要100 ms才能完全初始化，而一個容器實例必須響應完當前請求之后，才能繼續(xù)響應下一請求，因此當counter向Computing Unit瞬時發(fā)送出n條請求時，能夠保證每條請求都產生一個全新的容器實例來對請求進行處理。在熱啟動實驗中，利用上一次被使用過的冷啟動容器來保證實驗是在熱啟動模式下完成的。在預熱實驗環(huán)節(jié)，本節(jié)利用阿里云提供的策略對counter和Computing Unit僅預熱出一個容器實例，而實際所需的剩下n-1個實例，則通過阿里云的擴容策略進行快速復制。

實驗結果如圖4所示，一次完整的預熱測試包括容器預熱和執(zhí)行計算任務2個過程。從圖4中可以看到，冷啟動情形下單次請求的執(zhí)行時長為7 300 ms，遠遠高出熱啟動情況下的執(zhí)行時長578 ms。而在本文提出的方法中，預熱時長大約為360 ms，執(zhí)行計算任務時長大約為4 500 ms。同冷啟動情形相比，利用阿里云平臺本身的快速擴容機制，預熱措施的確能夠有效地縮短冷啟動延遲。但是另一方面發(fā)現(xiàn)，無論是冷啟動還是預熱之后的執(zhí)行時長，都遠遠高于熱啟動情形下的執(zhí)行耗時。發(fā)生這種現(xiàn)象的原因可能有2個：第1是因為counter和多個Computing Unit本身的冷啟動延遲效應，在容器啟動時存在一定的延遲；第2則是2種情形下的容器環(huán)境并沒有加載完全，而熱啟動的測試都是在冷啟動環(huán)境執(zhí)行多次后進行的測試。

Figure 4 Result of π computing task圖4 多容器計算π的實驗結果

5 結束語

高性能計算任務已經被證明能夠有效運行在函數計算平臺上，但其對計算資源的需求非常高，尤其是當整個任務被劃分為大量子任務時，需要平臺提供大量的容器實例來滿足其執(zhí)行需求。在并發(fā)任務過多的情形下，由于需要產生多個實例，同時可能需要進行一些結果同步的操作(比如4.3節(jié))，冷啟動延遲會嚴重增加單次任務執(zhí)行的總耗時，本文提出一種結合快速擴容機制進行提前預熱的方法來解決該問題。整個過程非常簡單，只需要利用時間序列分析工具預測請求到來的時間點，并在合適的時間段內利用信號將相應的云函數提前預熱即可。實驗結果表明，無論在單容器實例情形還是多容器協(xié)同計算情形下，本文方法都可以在一定程度上減少冷啟動延遲。未來的工作需要更多地去探索其他高性能應用場景來驗證本文方法。