幾個月前，我們發布了 Encore.ts — TypeScript 的開源後端框架。
由於已經有很多框架，我們想分享我們所做的一些異常設計決策以及它們如何帶來卓越的效能數據。
我們最近發布的效能基準顯示，Encore.ts 的請求吞吐量是 Express.js 的 9 倍，是 Fastify 的 2 倍。
今天，我們將繼續我們的效能之旅，深入探討 Encore.ts 如何實現令人難以置信的快速冷啟動啟動時間。
這次我們對 Encore.ts、Fastify、NestJS 和 Express 進行了基準測試，以了解每個框架在冷啟動時的表現。
基準測試程式註冊了 10 個 API 端點，每個端點都有一個簡單的模式，並設定模式驗證。
對於模式驗證，我們盡可能使用 Zod。
就 Fastify 而言，我們使用 Ajv 作為官方支援的模式驗證庫。
我們測量了從 JavaScript 程式碼開始執行到伺服器準備好接受傳入請求的時間。
對於每個基準測試，我們選取五次運行中的最佳結果。
廢話不多說了，讓我們深入研究一下數字吧！
(查看 GitHub 上的基準程式碼。)
如您所見，Encore.ts 實現了驚人的快速冷啟動時間，比 Express 快 5 倍以上，比 NestJS 快 17 倍以上。
這怎麼可能？透過我們的測試，我們確定了性能的兩個主要來源，都與 Encore.ts 的底層工作方式有關。
但在我們開始之前，我們先來談談冷啟動到底是什麼，以及為什麼它們重要。
在無伺服器環境中，冷啟動是指底層平台首先需要啟動伺服器的新實例以服務傳入請求。 （它也可以指第一次啟動伺服器的新實例來處理請求，例如在部署之後。）
由於請求實際上處於擱置狀態，直到進程啟動並準備好處理請求為止，因此減少冷啟動時間會對應用程式的長尾延遲產生很大影響。
這對於擁有多個無伺服器功能的分散式系統尤其重要，因為在處理請求時，您更有可能在系統的某些部分遇到冷啟動。
冷啟動期間發生的具體情況在一定程度上取決於您要部署到的平台（Kubernetes、Lambda、Cloud Run 等）。
但總的來說，這個過程看起來像這樣：
完成這些初始化步驟後，冷啟動完成，無伺服器函數開始處理傳入請求。
前兩個步驟很大程度上是我們無法控制的（除了確保程式碼/容器的大小已最佳化），所以讓我們將注意力集中在第三步上。
事實上，讓我們進一步分解第三步，假設我們正在執行 Node.js：
最後，在載入所有依賴項並執行所有初始化程式碼後，容器/無伺服器函數已準備好處理傳入請求。
上面的細分為我們提供了明確的最佳化目標，Encore.ts 大力優化了它控制的所有步驟。
Encore.ts 在 Rust 中實作並作為本機模組載入到 Node.JS 中。這對於冷啟動有幾個好處：
需要解析和執行的 JavaScript 更少。由於 JavaScript 是一種解釋性語言，因此所有 JavaScript 程式碼都需要從磁碟讀取、解析和執行。 Encore.ts 作為預先編譯的原生模組，載入速度極快，不需要 JavaScript 引擎（V8）解析或執行。
零 NPM 依賴。由於 Encore.ts 使用 Rust 實現其所有功能，因此它沒有任何 NPM 依賴項，這進一步減少了冷啟動期間需要執行的 JavaScript 數量。
預編譯與最佳化。 JavaScript 嚴重依賴即時編譯 (JIT)，其中重複執行的程式碼會被 JavaScript 引擎最佳化。這對於解釋型語言來說很有意義，但這也意味著第一次執行一段程式碼時執行速度會相當慢，這會顯著影響冷啟動。由於 Encore.ts 是用 Rust 實現的，因此它是預先編譯的，並針對其運行的平台進行了大量最佳化，這意味著它從第一次執行起就很快。
Encore.ts 預設會建立縮小的 Docker 映像，僅包含轉譯的 JavaScript 和執行應用程式所需的依賴項。這減少了套件的大小，從而減少了下載和啟動容器所需的時間。
此外，一些計算平台還添加了對流式 Docker 映像的支持，這意味著該平台可以在下載整個映像之前啟動容器。 Encore.ts 對此有內建支持，並自動優先考慮影像中需要減少冷啟動的部分。
透過將 Rust 運行時與優化的 Docker 映像相結合，Encore.ts 能夠實現顯著的冷啟動時間，這會對應用程式的長尾延遲產生很大影響。
如果效能對您的專案很重要，嘗試 Encore.ts 可能是個好主意。
而且它都是開源的，因此您可以查看程式碼並在 GitHub 上做出貢獻。
或嘗試一下，讓我們知道您的想法！
以上是Encore.ts — 比 NestJS 和 Fastify 更快的冷啟動的詳細內容。更多資訊請關注PHP中文網其他相關文章！
