ランバ LLRT

免責事項: 投稿されたすべてのコンテンツは、私の知識を思い出させたり維持したりすることを目的としており、学習を通じてあなたの旅に役立つことを願っています。
この投稿は公開されており、定期的に更新されます。
欠陥を見つけたり、何かが足りないことに気付いた場合は、改善にご協力ください :)

---

アプリケーションのパフォーマンスに対する要求がますます高まっていると考えたことはありますか?
私たちは毎日、より高速化することを奨励され、それによって結果を達成できるソリューションとアーキテクチャを評価するようになりました。

---

そこで、AWS Lambda のサーバーレス アプリケーションのパフォーマンスをかなり向上させるのに役立つ新しい進化について知らせる短い投稿を投稿することが目的です。このソリューションは LLRT Javascript です。

LLRT Javascript (低遅延ランタイム Javascript)

新しい Javascript ランタイムが aws チームによって開発されています。
現在は実験段階であり、2024 年末までに安定版をリリースできるよう取り組んでいます。

AWS が提供する説明を参照してください:

LLRT (低遅延ランタイム) は、高速で効率的なサーバーレス アプリケーションに対する需要の高まりに対応するために設計された軽量の JavaScript ランタイムです。 LLRT は、AWS Lambda で実行される他の JavaScript ランタイムと比較して、最大 10 倍以上の高速な起動と最大 2 倍の全体コストの削減を実現します
Rust に組み込まれており、QuickJS を JavaScript エンジンとして利用し、効率的なメモリ使用と迅速な起動を保証します。

他の JS ランタイムよりも最大 10 倍高速に何かを提供することを目指していることがわかります。

この構築はすべて、高性能言語である Rust と、小型で効率的で最新の ECMAScript 仕様と互換性を持つように設計された軽量で高性能な JavaScript エンジンである QuickJS を使用して行われます。クラス、async/await、モジュールなどの最新の機能が含まれます。さらに、JITを使用しないアプローチが使用されます。したがって、ジャストインタイム コンパイルにリソースを割り当てるのではなく、コード自体内のタスクを実行するためにこれらのリソースを保存します。

でも心配しないでください、すべてがバラ色というわけではありません、それはトレードオフです（ひどい駄洒落ですね、笑）。
したがって、LLRT JS の採用を検討する前に考慮すべき重要な点がいくつかあります。 AWS のコメントを参照してください:

大規模なデータ処理、モンテカルロ シミュレーション、数十万回または数百万回の反復を伴うタスクの実行など、LLRT が JIT を利用したランタイムと比較して顕著なパフォーマンス上の欠点を示すケースが数多くあります。 LLRT は、データ変換、リアルタイム処理、AWS サービス統合、認可、検証などのタスク専用の小規模なサーバーレス機能に適用すると最も効果的です。すべてを包括的に置き換えるものとしてではなく、既存のコンポーネントを補完するように設計されています。特に、サポートされている API が Node.js 仕様に基づいているため、代替ソリューションに戻すには最小限のコード調整が必要です。

また、LLRT JS は、node.js の代替ではなく、今後も代替される予定はないという考えです。

参照:

LLRT は Node.js API の一部のみをサポートします。これは Node.js に代わるものではありません。また、今後もその予定はありません。以下は、部分的にサポートされている API とモジュールの概要です。詳細については、API ドキュメントを参照してください。

---

評価試験

AWS 自体が述べた適用性を考慮して、LLRT と NodeJS を評価および比較する 2 つのテストを実行します。テストの 1 つは素数の計算用で、もう 1 つは単純な API 呼び出し用です。

なぜ素数の計算を使用するのですか?
その答えは、素数を識別するために必要な高度な処理は、素数を検証するために多くの数学的演算 (除算) を実行する必要性、素数の予測不可能な分布、および数値のサイズの増加に伴う複雑さの結果であるということです。これらの要素が組み合わさって、特に大規模な場合、素数検査と素数の検索が計算量の多いタスクになります。

---

それでは実践してください...

nodejs を使用して最初のラムダ関数を作成します:

次に、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 の柔軟性を確認し、JS がどれだけのことを実現できるか、また今後どれだけの成果をもたらすことができるかを知るのは素晴らしいことです。

---

楽しんでいただき、何かについての理解を深めたり、新しい知識への道を開いたりするのに役立ってくれれば幸いです。コンテンツを改善し、コミュニティのために常に最新の状態に保つことができるよう、皆様の批判や提案をお待ちしております。

以上がランバ LLRTの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。