awslabs / awslabs/llrt

Rerun the benchmark?

Open
#1,166 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
8.8k
Forks
394
Avg merge
1d 11h
Merged PRs (30d)
45

Description

Is it possible to rerun the benchmark with the latest release? Since January 2024, the llrt binaries have grown 2+ MB. I've been doing some coldstart benchmarking to compare LLRT standard sdk with Node 22. My test using arm in us-east-2 instantiates a STS client and invokes get-caller-identity. It isn't quite the same as a ddb put, but it's similar enough that I'd expect the http and λ times to be close to yours on coldstarts. In the table below http means time recorded from the client and λ is time from the invocation logs like yours. Overhead means http - λ. I'm noticing that the overhead in the cold start is higher for LLRT than when using the Node 22 runtime by about 50 ms. I also notice that my p50 for http is ~40 ms higher than your benchmark, but λ is ~17 ms higher. I suspect the increase in binary size is the main contributor, but if you can rerun the benchmarks that will help narrow down what is causing the deltas.

Test memory samples p0(http) p50(http) p99(http) p50(overhead) p0(λ) p50(λ) p99(λ)
LLRT v.0.7.0-beta 128 140 186 275 357 193 61 81 128
Node 22 AwsLite 512 140 344 409 492 144 208 260 326
Node 22 v3 SDK w/optimizations 512 140 369 447 543 144 248 300 363
Node 22 v3 SDK minified 512 140 460 547 640 151 320 393 464
Node 22 v3 SDK from disk 512 140 557 681 788 145 444 535 633

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with example/functions/src/v3-lib.mjs and the benchmark setup described in the issue. Rerun the LLRT and Node 22 cold-start comparison using the stated ARM, us-east-2, STS get-caller-identity scenario, then compare the HTTP, invocation, and overhead measurements with the reported table. Done means updated results that help assess whether binary growth explains the deltas.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, javascript, node.js
Domain
cloud, performance
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.