https://kotlinlang.org logo
Channels
100daysofcode
100daysofkotlin
100daysofkotlin-2021
advent-of-code
aem
ai
alexa
algeria
algolialibraries
amsterdam
android
android-architecture
android-databinding
android-studio
androidgithubprojects
androidthings
androidx
androidx-xprocessing
anime
anko
announcements
apollo-kotlin
appintro
arabic
argentina
arkenv
arksemdevteam
armenia
arrow
arrow-contributors
arrow-meta
ass
atlanta
atm17
atrium
austin
australia
austria
awesome-kotlin
ballast
bangladesh
barcelona
bayarea
bazel
beepiz-libraries
belgium
benchmarks
berlin
big-data
books
boston
brazil
brikk
budapest
build
build-tools
bulgaria
bydgoszcz
cambodia
canada
carrat
carrat-dev
carrat-feed
chicago
chile
china
chucker
cincinnati-user-group
cli
clikt
cloudfoundry
cn
cobalt
code-coverage
codeforces
codemash-precompiler
codereview
codingame
codingconventions
coimbatore
collaborations
colombia
colorado
communities
competitive-programming
competitivecoding
compiler
compose
compose-android
compose-desktop
compose-hiring
compose-ios
compose-mp
compose-ui-showcase
compose-wear
compose-web
confetti
connect-audit-events
corda
cork
coroutines
couchbase
coursera
croatia
cryptography
cscenter-course-2016
cucumber-bdd
cyprus
czech
dagger
data2viz
databinding
datascience
dckotlin
debugging
decompose
decouple
denmark
deprecated
detekt
detekt-hint
dev-core
dfw
docs-revamped
dokka
domain-driven-design
doodle
dsl
dublin
dutch
eap
eclipse
ecuador
edinburgh
education
effective-kotlin
effectivekotlin
emacs
embedded-kotlin
estatik
event21-community-content
events
exposed
failgood
fb-internal-demo
feed
firebase
flow
fluid-libraries
forkhandles
forum
fosdem
fp-in-kotlin
framework-elide
freenode
french
fritz2
fuchsia
functional
funktionale
gamedev
ge-kotlin
general-advice
georgia
geospatial
german-lang
getting-started
github-workflows-kt
glance
godot-kotlin
google-io
gradle
graphic
graphkool
graphql
graphql-kotlin
graviton-browser
greece
grpc
gsoc
gui
hackathons
hacktoberfest
hamburg
hamkrest
helios
helsinki
hexagon
hibernate
hikari-cp
hire-me
hiring
hiring-french
hongkong
hoplite
http4k
hungary
hyderabad
image-processing
india
indonesia
inkremental
intellij
intellij-plugins
intellij-tricks
internships
introduce-yourself
io
ios
iran
israel
istanbulcoders
italian
jackson-kotlin
jadx
japanese
jasync-sql
java-to-kotlin-refactoring
javadevelopers
javafx
javalin
javascript
jdbi
jhipster-kotlin
jobsworldwide
jpa
jshdq
juul-libraries
jvm-ir-backend-feedback
jxadapter
k2-early-adopters
kaal
kafka
kakao
kalasim
kapt
karachi
karg
karlsruhe
kash_shell
kaskade
kbuild
kdbc
kgen-doc-tools
kgraphql
kinta
klaxon
klock
kloudformation
kmdc
kmm-español
kmongo
knbt
knote
koalaql
koans
kobalt
kobweb
kodein
kodex
kohesive
koin
koin-dev
komapper
kondor-json
kong
kontent
kontributors
korau
korean
korge
korim
korio
korlibs
korte
kotest
kotest-contributors
kotless
kotlick
kotlin-asia
kotlin-beam
kotlin-by-example
kotlin-csv
kotlin-data-storage
kotlin-foundation
kotlin-fuel
kotlin-in-action
kotlin-inject
kotlin-latam
kotlin-logging
kotlin-multiplatform-contest
kotlin-mumbai
kotlin-native
kotlin-pakistan
kotlin-plugin
kotlin-pune
kotlin-roadmap
kotlin-samples
kotlin-sap
kotlin-serbia
kotlin-spark
kotlin-szeged
kotlin-website
kotlinacademy
kotlinbot
kotlinconf
kotlindl
kotlinforbeginners
kotlingforbeginners
kotlinlondon
kotlinmad
kotlinprogrammers
kotlinsu
kotlintest
kotlintest-devs
kotlintlv
kotlinultimatechallenge
kotlinx-datetime
kotlinx-files
kotlinx-html
kotrix
kotson
kovenant
kprompt
kraph
krawler
kroto-plus
ksp
ktcc
ktfmt
ktlint
ktor
ktp
kubed
kug-leads
kug-torino
kvision
kweb
lambdaworld_cadiz
lanark
language-evolution
language-proposals
latvia
leakcanary
leedskotlinusergroup
lets-have-fun
libgdx
libkgd
library-development
lincheck
linkeddata
lithuania
london
losangeles
lottie
love
lychee
macedonia
machinelearningbawas
madrid
malaysia
mathematics
meetkotlin
memes
meta
metro-detroit
mexico
miami
micronaut
minnesota
minutest
mirror
mockk
moko
moldova
monsterpuzzle
montreal
moonbean
morocco
motionlayout
mpapt
mu
multiplatform
mumbai
munich
mvikotlin
mvrx
myndocs-oauth2-server
naming
navigation-architecture-component
nepal
new-mexico
new-zealand
newname
nigeria
nodejs
norway
npm-publish
nyc
oceania
ohio-kotlin-users
oldenburg
oolong
opensource
orbit-mvi
osgi
otpisani
package-search
pakistan
panamá
pattern-matching
pbandk
pdx
peru
philippines
phoenix
pinoy
pocketgitclient
polish
popkorn
portugal
practical-functional-programming
proguard
prozis-android-backup
pyhsikal
python
python-contributors
quasar
random
re
react
reaktive
realm
realworldkotlin
reductor
reduks
redux
redux-kotlin
refactoring-to-kotlin
reflect
refreshversions
reports
result
rethink
revolver
rhein-main
rocksdb
romania
room
rpi-pico
rsocket
russian
russian_feed
russian-kotlinasfirst
rx
rxjava
san-diego
science
scotland
scrcast
scrimage
script
scripting
seattle
serialization
server
sg-user-group
singapore
skia-wasm-interop-temp
skrape-it
slovak
snake
sofl-user-group
southafrica
spacemacs
spain
spanish
speaking
spek
spin
splitties
spotify-mobius
spring
spring-security
squarelibraries
stackoverflow
stacks
stayhungrystayfoolish
stdlib
stlouis
strife-discord-lib
strikt
students
stuttgart
sudan
swagger-gradle-codegen
swarm
sweden
swing
swiss-user-group
switzerland
talking-kotlin
tallinn
tampa
teamcity
tegal
tempe
tensorflow
terminal
test
testing
testtestest
texas
tgbotapi
thailand
tornadofx
touchlab-tools
training
tricity-kotlin-user-group
trójmiasto
truth
tunisia
turkey
turkiye
twitter-feed
uae
udacityindia
uk
ukrainian
uniflow
unkonf
uruguay
utah
uuid
vancouver
vankotlin
vertx
videos
vienna
vietnam
vim
vkug
vuejs
web-mpp
webassembly
webrtc
wimix_sentry
wwdc
zircon
Powered by
Title
d

dave

02/04/2023, 6:52 PM
HI http4kers! Quick update for those of you that are running on Serverless AWS Lambda. As well as the the existing support for the various Lambda runtimes that we already supported (standard AWS (x86 and Graviton), custom http4k-JVM and GraalVM), we've just pushed support for running the http4k-JVM runtime on Graviton2 via the official http4k Docker Images. We've also upgraded the underlying infra so we're on the latest versions of Amazon Linux, Java (11,17,19) and Graal 🙃 This means you can take advantage of the both the better cost savings of Graviton and the http4k runtime to get better performance and lower memory footprint for less 💵 , even if you don't want to go all the way to compiling to native with GraalVM. There's a fully working example in the examples repo which uses Pulumi to setup the infrastructure, or you can go straight to the amd64 docker image repo to see how it works from the command line 🙂
a

Andrew O'Hara

02/04/2023, 7:06 PM
What is the advantage of running on the custom runtime? Does it just strip jackson from the classpath? Is this a worthwhile tradeoff against the cold-start hit you presumably get from using a docker image instead of an official runtime?
d

dave

02/04/2023, 7:25 PM
From our (fairly unscientific admittedly 😉) experiments we see that it's significantly faster to startup from cold than the official one you might see. And it's not just the embedded Jackson initialisation that's bloating out the standard release - both in terms of size and launch speed - memory is hazy but pretty sure that I also saw log4j in there as well when I was investigating which didn't help. The custom adapter layer for the AWS events that we have built into the http4k runtime is based on Moshi, so that's much smaller/faster as well as there is no reflection at all required. There is definitely an experiment to be done to compare all these things - I have a half finished repo where we compare across AWS/http4k/Graal runtimes, various serverless implementations for http4k, spring, micronaut, quarkus, and AWS SDK vs http4k-connect. Snapstart will make yet another variant to all this to compare - or just might make the entire comparison moot! 😂 There's also a trade off between lambda-size, memory,cold start time, build time (aka cycle time), and performance. I think it's all about options TBH and what your use-case is and how that all fits into the cost. As always, YMMV so for us it's all about giving people options! BTW - the docker images that we have above don't produce an image - they output a self-contained function ZIP file which runs on AmazonLinux2 - if that ends up in a docker image in lambda is unknown to me 🙂 .
a

Andrew O'Hara

02/05/2023, 3:28 AM
Well, I don't even have snapstart in ca-central-1, so I'll give it a shot! Any particular reason you stuck to java 11? I've been itching to upgrade my lambdas to 17.
d

dave

02/05/2023, 3:33 AM
No reason. There are images for 17 and 19 as well.' 🙃
Will be interesting to hear your experiences so please report back ! 🙃
a

Andrew O'Hara

02/05/2023, 3:42 AM
Oh, I think I see how it works. The docker image isn't the lambda runtime; it's just a script that packages the jar to run with a bundled jvm on an AL2 runtime. I'll have to see if I can get this to work with SAM. Maybe tomorrow.
So, here's the results of my tests. My testbed was a small but fully featured rest API with nimbus JWT authorization and a swagger UI. There is a 7 MB reflectionless variant (with kotlinx-serialization), and a 10 MB variant with moshi-kotlin. All functions were running with 2048 MB memory and JIT optimized for cold-start (-XX:+TieredCompilation -XX:TieredStopAtLevel=1). Kotlinx-serialization on java11 runtime java11 runtime init: 350 ms App init: 1100 ms request: 50 ms Kotlinx-serialization on custom runtime provided.al2 runtime init: 380 ms custom runtime init: 500 ms app init: 550 ms request: 60 ms Moshi-Kotlin on java11 runtime java11 runtime init: 250 ms App init: 1500 ms request: 60 ms Moshi-Kotlin on custom runtime provided.al2 runtime init: 350 ms custom runtime init: 500 ms App init: 1000 ms request: 60 ms While David has demonstrated some truly impressive (125 ms) cold-start times, I haven't been able to get the same improvement for my function. I would be very interested to see what results others can produce. See updated results below. I was mistaken about the example's impressive 125 ms cold-start time; it had 1100 ms.
d

dave

02/07/2023, 5:17 PM
Thanks @Andrew O'Hara! Those super-fast times I demonstrated have admittedly been with a super lightweight function (no http4k-contract or outbound HTTP calls involved), but we did use Moshi with reflection in there. A further investigation is needed to see what's going on because the disparity is weird.. 🤔
a

Andrew O'Hara

02/07/2023, 5:41 PM
Yeah, I should try working from the other way around: with a minimal function and slowly adding more components.
So here's the (updated) results of my tests, following some further optimizations I discovered with David. The built-in java11 runtime is still hard to beat if you have optimized dependencies. I'm still very interested to see if people can get better results with the custom runtime. An interesting thing to note is that the
Java8HttpClient
has a much better cold start time than the (usually recommended)
JavaHttpClient
. And of course, eliminating reflection will always result in better performance. I will however note that if you need features from newer JREs (beyond 11), the custom runtime is a great way to make them available on Lambda. https://docs.google.com/spreadsheets/d/1bMM6YygmCZUeCHeB326bUIZcoaeQWNbU1x78DGX6hYM/edit?usp=sharing