為了盡量減少冷啟動，我為我的谷歌云函式設定了一個最小實體。我實際上是用這樣的 firebase admin SDK 來做的：
functions.runWith({ minInstances: 1 })
...但我可以在 Google Cloud Console 中看到它得到確認：
我注意到每次部署后，我仍然會遇到一個冷啟動。我會假設一個實體已準備好并準備好接受第一個請求，但事實似乎并非如此。例如，以下是日志：
您可以看到部署后約 16 小時，第一個請求進來。這是一個冷啟動，需要 8139 毫秒。下一個請求大約在一個小時后到來，但沒有冷啟動，請求需要 556 毫秒，比第一個請求快得多。
這是預期的行為嗎？即使設定了最小實體，我們還會遇到冷啟動嗎？然后，我是否應該在每次部署后使用虛擬請求啟動云功能，以防止我的用戶遇到第一次冷啟動？
uj5u.com熱心網友回復：
Tl;dr：具有最小實體集的函式的第一次執行在技術上不是冷啟動，但可能會比該實體的后續執行慢。
函式的最小實體將在部署時立即“預熱”，并處于溫暖但空閑的狀態，準備好回應請求。但是，我們撰寫的函式在第一次實際觸發時通常需要進行額外的設定作業。
例如，我們可能使用動態匯入來拉入庫或需要建立與遠程資料庫的連接。即使函式實體是溫暖的，但必須在第一次執行時完成的額外作業意味著它可能會比以后的執行慢。
最小實體設定的好處是，以后的執行可以從第一次執行完成的所有設定作業中受益，并且可以比將它們縮小到零并在下一次請求時重新設定自己要快得多。
更新：有時，空閑實體可能會被 Cloud Functions 后端殺死。如果發生這種情況，將立即啟動另一個實體以滿足所需的最小實體設定，但該新實體將需要在第一次觸發時再次完成其額外的設定作業。但是，這確實不應該經常發生。
uj5u.com熱心網友回復：
該檔案沒有對行為做出硬性保證（強調我的）：
為了最大程度地減少冷啟動的影響，Cloud Functions會在處理請求后嘗試讓函式實體在未指定的時間內保持空閑狀態。
所以，有一個嘗試（不能保證），它在處理請求后啟動（而不是在部署后），但你不知道它會持續多久。如前所述，聽起來您可能想要提出請求，并期望它可能仍無法始終按照您想要的方式作業。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/421181.html
標籤：