1. 首頁 > 科技 > >

小米科技|Spring Boot Serverless 實戰系列 | 性能調優( 二 )

小米科技


在函數計算控制臺 ， 我們可以在“彈性伸縮”頁面為函數設置預留實例 。

用戶在控制臺中配置最小和最大實例數 。 平臺會預留最小實例數目的實例 ， 最大實例是指該函數下實例的上限 。 用戶也可以設置定時預留和按指標預留的規則 。

創建預留規則后 ， 系統就會創建預留實例 。 當預留實例就緒后 ， 我們再訪問函數就不會有冷啟動 。

1.2. 優化實例啟動速度
延遲初始化
在 Spring Boot 2.2 及更高版本中 ， 可以開啟一個全局延遲初始化標志 。 這將提高啟動速度 ， 但代價是第一個請求的延遲時間可能變長 ， 因為需要等待組件首次初始化 。
可在 s.yaml 中為相關應用配置以下環境變量
SPRING_MAIN_LAZY_INITIATIALIZATION=true
關閉優化編譯器
默認情況下 ， JVM 有多個階段的 JIT 編譯 。 雖然這些階段可以逐漸提高應用的效率 ， 但它們也會增加內存使用的開銷 ， 并增加啟動時間 。 對于短期運行的 Serverless 應用 ， 請考慮關閉此優化 ， 以犧牲長期效率換取更短的啟動時間 。
可在 s.yaml 中為相關應用配置以下環境變量：
JAVA_TOOL_OPTIONS=\"-XX:+TieredCompilation -XX:TieredStopAtLevel=1\"
s.yaml 中設置環境變量示例：
如下圖所示 ， 對 mall-admin 函數配置環境變量 。 然后執行 sudo -E s mall-admin deploy 部署 。

登錄實例檢查環境變量是否配置正確
在控制臺函數詳情頁的請求列表中找到對應的請求 ， 點擊更多中的“實例詳情鏈接” 。

在實例詳情頁中點擊“登錄實例” 。

在 shell 界面中執行 echo 命令 ， 查看對應的環境變量是否設置正確 。
注意：對于非預留實例 ， 一段時間沒有請求后 ， 函數計算系統會自動回收實例 。 此時無法再登入實例（上面的實例詳情頁面中的登錄實例按鈕會變灰） 。 所以請執行調用后 ， 在實例被回收之前盡快登錄 。

配置合理的實例參數 當我們選擇了應用實例規格 ， 比如 2C4G 或者 4C8G ， 接下來我們希望知道一個實例處理多少請求可以既能充分利用資源又能夠保證性能 。 當處理的請求超過一個限制后 ， 系統能夠快速彈出實例 ， 保證應用性能平滑 。 如何度量實例過載有多個維度 ， 例如 qps 超過一定閾值 ， 或者實例 CPU/Memory/Network/Load 等指標超過閾值等等 。 函數計算使用實例并發度（Instance Concurrency）來作為實例負載的度量和實例伸縮的依據 。 實例并發度（Instance Concurrency）是指一個實例能同時執行的請求數 。 例如將實例并發度設置為 20 ， 則意味著一個實例在任意時刻最大能同時執行 20 個請求 。
注意：請區分實例并發度和 QPS 的區別 。
使用實例并發度來度量負載有如下優勢：
系統能夠迅速統計實例并發度指標值進行擴縮容 。 CPU/Memory/Network/Load 等實例級別的指標通常是后臺統計 ， 需要花費數十秒的指標統計后才能進行伸縮 ， 難以滿足在線應用的彈性伸縮要求 。在各種條件下 ， 實例并發度指標都能夠穩定的反映系統負載高低 。 如果以請求延時作為指標 ， 系統難以區分是實例過載導致延時變大 ， 還是下游服務成為瓶頸導致延時變大 。 例如一個典型的 Web 應用 ， 通常會訪問 MySQL 數據庫 。 如果數據庫成為瓶頸 ， 請求延時變大 ， 此時擴容不但毫無意義 ， 而且會壓垮數據庫 ， 讓情況更加惡化 。 QPS 和請求延時相關 ， 也會有上述問題 。實例并發度作為伸縮依據雖然有上述優點 ， 但用戶常常并不知道該設置多大的實例并發度 。 我推薦按照下述流程確定合理的并發度：

相關經驗推薦