免責聲明:發布的所有內容都是為了提醒或維護我的知識,我希望它也能在您的學習之旅上有所幫助。
這篇文章是即時的,並將定期更新。
如果您發現任何缺陷或發現缺少某些內容,請幫我改進:)
您是否曾經想過,我們對應用程式效能的要求越來越高?
我們每天都被鼓勵讓它們更快,這樣我們就可以評估解決方案和架構,使我們能夠實現結果。
因此,我們的想法是發表一篇簡短的文章,介紹一項新的演變,可以幫助我們顯著提高 AWS Lambda 中無伺服器應用程式的效能。這個解決方案是LLRT Javascript。
aws 團隊正在開發新的 Javascript 執行階段。
目前處於實驗階段,我們正在努力嘗試在 2024 年底前發布穩定版本。
請參閱 AWS 提供的描述:
LLRT(低延遲運行時)是一種輕量級 JavaScript 運行時,旨在滿足對快速高效的無伺服器應用程式不斷增長的需求。與 AWS Lambda 上運行的其他 JavaScript 運行時相比,LLRT 的啟動速度提高了 10 倍以上,整體成本降低了 2 倍
它採用 Rust 構建,利用 QuickJS 作為 JavaScript 引擎,確保高效的記憶體使用和快速啟動。
看到他們的目標是提供比其他 JS 運行時快 10 倍的東西。
所有這些建置都是使用 Rust(一種高效能語言)和 QuickJS 完成的,QuickJS 是一種輕量級高效能 JavaScript 引擎,設計小巧、高效且與最新的 ECMAScript 規範相容。現代功能,如類別、非同步/等待和模組。此外,使用了不使用JIT的方法。因此,它不是為即時編譯分配資源,而是保留這些資源用於在程式碼本身內執行任務。
但別擔心,並不是一切都是美好的,這是權衡(可怕的雙關語,我知道哈哈)。
因此,在考慮採用 LLRT JS 之前,需要考慮一些重要的要點。看看 AWS 怎麼說:
在許多情況下,LLRT 與 JIT 支援的運行時相比表現出明顯的效能缺陷,例如大數據處理、蒙特卡羅模擬或執行數十萬或數百萬次迭代的任務。當應用於專用於資料轉換、即時處理、AWS 服務整合、授權、驗證等任務的小型無伺服器功能時,LLRT 最為有效。它旨在補充現有組件,而不是作為所有組件的全面替代品。值得注意的是,鑑於其支援的 API 是基於 Node.js 規範,轉換回替代解決方案需要最少的程式碼調整。
此外,我們的想法是 LLRT JS 不會取代 Node.js,也永遠不會取代。
參見:
LLRT 僅支援 Node.js API 的一小部分。它不是 Node.js 的替代品,也永遠不會。以下是部分支援的 API 和模組的高階概述。有關更多詳細信息,請參閱 API 文件。
考慮到AWS本身提到的適用性,我們將進行兩次測試來評估和比較LLRT與NodeJS。其中一項測試將用於計算素數,另一項測試將用於簡單的 API 呼叫。
為什麼要用質數的計算?
答案是,識別素數所需的高處理能力是由於需要執行許多數學運算(除法)來驗證素數、素數的不可預測的分佈以及隨著數字的大小而增加的複雜性。這些因素結合在一起,使得素性檢查和素數搜尋成為一項計算密集型任務,尤其是在大規模情況下。
動手吧...
使用 Nodejs 建立第一個 lambda 函數:
現在,讓我們使用 LLRT JS 來建立該函數。我選擇使用圖層選項。
建立圖層:
然後建立函數:
並將該層加入建立的 LLRT JS 函數:
對於素數測試,我們將使用以下程式碼:
let isLambdaWarm = false export async function handler(event) { const limit = event.limit || 100000; // Defina um limite alto para aumentar a complexidade const primes = []; const startTime = Date.now() const isPrime = (num) => { if (num <= 1) return false; if (num <= 3) return true; if (num % 2 === 0 || num % 3 === 0) return false; for (let i = 5; i * i <= num; i += 6) { if (num % i === 0 || num % (i + 2) === 0) return false; } return true; }; for (let i = 2; i <= limit; i++) { if (isPrime(i)) { primes.push(i); } } const endTime = Date.now() - startTime const response = { statusCode: 200, body: JSON.stringify({ executionTime: `${endTime} ms`, isLambdaWarm: `${isLambdaWarm}` }), }; if (!isLambdaWarm) { isLambdaWarm = true } return response; };
對於 API 測試,我們將使用以下程式碼:
let isLambdaWarm = false export async function handler(event) { const url = event.url || 'https://jsonplaceholder.typicode.com/posts/1' console.log('starting fetch url', { url }) const startTime = Date.now() let resp; try { const response = await fetch(url) const data = await response.json() const endTime = Date.now() - startTime resp = { statusCode: 200, body: JSON.stringify({ executionTime: `${endTime} ms`, isLambdaWarm: `${isLambdaWarm}` }), } } catch (error) { resp = { statusCode: 500, body: JSON.stringify({ message: 'Error fetching data', error: error.message, }), } } if (!isLambdaWarm) { isLambdaWarm = true } return resp; };
這裡的目標更具教育意義,因此我們每次測試的樣本由 15 個熱啟動數據和 1 個冷啟動數據組成。
記憶體消耗
LLRT JS - 對於這兩個測試,消耗了相同的記憶體量:23mb。
NodeJS - 對於質數測試,nodejs 開始消耗 69mb 並上升到 106mb。
對於 API 測試,最小值為 86mb,最大值為 106mb。
執行時間
刪除異常值後,結果如下:
最終報告
記憶體消耗 - 對於記憶體消耗,我們觀察到 LLRT 比 Nodejs 更好地利用了可用資源。
效能 - 我們注意到,在高處理場景下,無論是冷啟動還是熱啟動,節點都保持了比 LLRT 高得多的效能。
對於較低的處理場景,LLRT 有一定的優勢,尤其是在冷啟動方面。
然後讓我們等待最終結果,並希望我們能夠有更顯著的改進,但是很高興看到 JS 的靈活性並看到它可以並且仍然需要為我們提供多少。
我希望你喜歡它,並幫助你提高對某些事物的理解,甚至開闢通往新知識的道路。我期待您的批評和建議,以便我們可以改進內容並始終為社區保持更新。
以上是蘭巴輕軌的詳細內容。更多資訊請關注PHP中文網其他相關文章!