GraalVM: build regular Micronaut Kotlin/Java lambdas, run natively

Pavel Fadeev — Tue, 26 Nov 2019 20:21:19 +0000

Finally! It’s time to forget about those cold starts and scheduled warm-up calls. Simply deploy Java (or Kotlin) natively compiled code to AWS Lambda! Or maybe not yet? The post is an attempt to answer this question with an experiment like:

deploy natively compiled (by GraalVM native-image tool) Kotlin and Java lambdas to AWS cloud
have the same setup with Node.js lambda nearby
bridge incoming calls through AWS API Gateway
run basic tests to measure cold start timings and see behaviour after warm-up

Project setup

Project boilerplate has been generated with Micronaut tooling and provisioned to AWS infrastructure using Serverless framework. Load testing delivered with K6. Feel free to explore related step-by-step setup guide to deploy the same setup and play with load tests.

Load scenarios

#1 “cold” starts evaluation

each lambda deployed 10 times (which guarantees to have init run for the first call after deployment)
the deployment followed by 10 seconds load test. The load test is strictly sequential, all requests issued one after another.
client-side statistics captured from K6 log output, AWS-side figures taken from CloudWatch Logs Insights with simplest queries.

#2 “warm” runs

each lambda deployed once and called to trigger initial iteration
deployment followed by 10 iterations, each with the same 10 seconds sequential load test

load test scenarios could be found here: cold-start run, warm run

Measurements and their visualization

Client-side measurements

“cold” start outliers are clearly visible. Their value reaches ~7.5 sec with no effort
on a bright side, other min/max/percentile figures distributed quite evenly across tested lambdas. JVM/native max numbers leaning a little towards bigger values
these slight fluctuations could be caused by the network layer as well. Next AWS-side measurements section might be used for cross-checks. client-side latency measurements data

AWS-side measurements

Node.js min numbers 0.84/0.79 ms(!) are invisible at this log-scale chart
alas, JVM-based lambdas show “cold” start numbers up to 5 sec. Add ~2.5 sec init time on top of this. Predictably sad
native Kotlin/Java lambdas’ performance looks fairly acceptable. Even the worst iteration kept close to 180 ms
it is worth to mention that enterprise GraalVM version features an opportunity to tweak performance with profile-guided optimizations. At the moment GraalVM Enterprise Edition licensed for free testing, evaluation, or for developing non-production applications only. Still, there is a hope to see this tooling within CE version as well…
init timings for native images (~330 ms) are much closer to Node.js ones (~160 ms) AWS-side latency measurements data (init time is out of scope)

here you may find exact numbers for client-side and AWS-side runs, including init timings and billing calculations

Summary notes

Java/Kotlin JVM lambdas are still experiencing “cold” start issues. These ~5–7 seconds is just a matter of fact today. Further manipulations with artefact size and classpath might help with init timings, but…
GraalVM native lambdas have sustainable performance profile. Init time (~330ms) comparable to Node.js reference lambda (~160ms) and way better than for JVM (~2.5 sec)
At the same time, GraalVM/Micronaut/Serverless combo instantly leverages from Java/Kotlin existing ecosystem, reach tooling and active community
Node.js timings are really good and very stable. Median is barely different from 99%-ile
in fact, Java and Kotlin -based native images have the same size, 14.62 MB. JVM images sizing is a little different: 38.58 MB (Java) and 44.37 MB (Kotlin). And Node.js size is just 297 bytes :)
Last but not least, this project is intentionally bent from autogenerated Micronaut template. This short journey has proven two things. #1: a lot of issues may arise during migration to *.gradle.kts, restructuring multi-module Gradle project and native-image configuration tweaks. #2: either these issues solved multiple times or solvable with reasonable efforts.

You may run described deployments and tests using project’s github repo.

DEV Community: Pavel Fadeev