首頁  >  文章  >  web前端  >  蘭巴輕軌

蘭巴輕軌

WBOY
WBOY原創
2024-08-21 06:14:05442瀏覽

免責聲明:發布的所有內容都是為了提醒或維護我的知識,我希望它也能在您的學習之旅上有所幫助。
這篇文章是即時的,並將定期更新。
如果您發現任何缺陷或發現缺少某些內容,請幫我改進:)


您是否曾經想過,我們對應用程式效能的要求越來越高?
我們每天都被鼓勵讓它們更快,這樣我們就可以評估解決方案和架構,使我們能夠實現結果。


因此,我們的想法是發表一篇簡短的文章,介紹一項新的演變,可以幫助我們顯著提高 AWS Lambda 中無伺服器應用程式的效能。這個解決方案是LLRT Javascript

LLRT Javascript(低延遲執行階段 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 函數:

Lamba LLRT

現在,讓我們使用 LLRT JS 來建立該函數。我選擇使用圖層選項。

建立圖層:
Lamba LLRT

然後建立函數:
Lamba LLRT

並將該層加入建立的 LLRT JS 函數:
Lamba LLRT

對於素數測試,我們將使用以下程式碼:

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。

執行時間
刪除異常值後,結果如下:

Lamba LLRT

Lamba LLRT

最終報告

記憶體消耗 - 對於記憶體消耗,我們觀察到 LLRT 比 Nodejs 更好地利用了可用資源。

效能 - 我們注意到,在高處理場景下,無論是冷啟動還是熱啟動,節點都保持了比 LLRT 高得多的效能。
對於較低的處理場景,LLRT 有一定的優勢,尤其是在冷啟動方面。

然後讓我們等待最終結果,並希望我們能夠有更顯著的改進,但是很高興看到 JS 的靈活性並看到它可以並且仍然需要為我們提供多少。


我希望你喜歡它,並幫助你提高對某些事物的理解,甚至開闢通往新知識的道路。我期待您的批評和建議,以便我們可以改進內容並始終為社區保持更新。

以上是蘭巴輕軌的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn