GraalVM Native Image を使用した Lambda 関数 - コールド スタートとウォーム スタートを評価する部分

導入

シリーズのパート 2 では、GraalVM 21 ランタイムを使用した GraalVM ネイティブ イメージを含むカスタム ランタイムを使用して、(Spring Boot 3 などのフレームワークを使用せずに) 純粋な Lambda 関数を開発およびデプロイする方法を検討しました。

この記事では、このアプローチを使用して Lambda 関数のパフォーマンス (コールド スタートとウォーム スタート) を測定します。

GraalVM ネイティブ イメージを含むカスタム ランタイムを使用した Lambda 関数のコールド スタートとウォーム スタートの測定

測定には、パート 2 のサンプル アプリケーションを使用し、すべての Lambda 関数に 1024 MB のメモリを与えます。

以下の実験の結果は、Lambda 関数 GetProductByIdWithPureJava21GraalVMNativeImageLambda を使用して、1 時間の間に 100 件を超えるコールド スタートと約 100,000 件のウォーム スタートを再現したことに基づいています。この関数は、製品 (保存されている) の取得を担当する Java Lambda ハンドラー クラスにマップされています。 DynamoDB 内) の ID で指定します。このために、負荷テスト ツールを使用しましたが、Serverless-artillery や Postman など、任意のツールを使用できます。

コールド (c) およびウォーム (m) の開始時間 (ミリ秒):

c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
525.77	532.12	542.32	632.56	635.73	636.11	4.16	4.69	5.46	12.30	37.25	211.83

結論

この記事では、GraalVM 21 ランタイムで GraalVM ネイティブ イメージを含むカスタム ランタイムを使用し、1024 MB のメモリを持つ純粋な Lambda 関数のパフォーマンス (コールド スタートとウォーム スタート) を測定しました。

これらのパフォーマンス測定を、記事「Java 21 でのコールド スタートとウォーム スタートの測定」の記事と比較すると、SnapStart を有効にし、DynamoDB リクエストのプライミングを使用して実行したさまざまな Lambda メモリ設定を使用して、コールド スタート時間とウォーム スタート時間がこれまでで最も短いことがわかります。 GraalVM Native Image を使用した場合と、純粋な Lambda 関数を SnapStart で使用した場合と比較し、プライミングについて説明しました。もちろん、SnapStart と GraalVM Native Image の両方のアプローチにも異なる利点と欠点があり、それについては別の記事で説明します。

公開時には、新しいバージョン (GraalVM 23 ランタイムなど) も利用可能になったので、場合によっては、バージョンを変更し、シリーズのパート 2 の手順に従って GraalVM ネイティブ イメージを再コンパイルし、Lambda パフォーマンスを再測定します。 .

メモリ設定は Lambda 関数の実行コストにも大きく影響するため、シリーズの次の記事では、さまざまな Lambda メモリ設定 (256 MB から 1536 MB) が Lambda のパフォーマンスに与える影響について調査します。

以上がGraalVM Native Image を使用した Lambda 関数 - コールド スタートとウォーム スタートを評価する部分の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。