Minor spoiler for my upcoming KotlinConf talk on g...
# http4k
a
Minor spoiler for my upcoming KotlinConf talk on getting good cold start times on AWS Lambda. The micronaut segment might be skipped for time though. Missing context is that the blue arrows are cold starts, and the yellow are restores from Lambda Snapstart.
http4k 5
๐Ÿš€ 6
I'm actually considering doing a last-minute evaluation of Quarkus now ๐Ÿ˜…
d
There's still time to do all of them! ๐Ÿ˜‰
j
So, snapstart... its worth it (I never used it, but I guess added complexity? Is it a lot?) to save 4.2s of start up, but is it worth it to save ~100ms? With graal.. I'm guessing startup is quicker?
d
Well remember you pay memory * time for lambda, so for sizeable scaling maybe it is?
(love the new slides btw @Andrew O'Hara ๐Ÿ™ƒ )
j
Genuine question. Sorry wasn't say it wasn't worth it! What are the tradeoffs here? In the lovely chart. The http4k (no snapstart) at 590ms, is already faster than the ~800ms spring boot(with snapstart).. so is it worth the snapstart? It could be, if it's super easy.. I never did, so I'd love to know if it is or isn't.
d
@James Richardson you could come to copenhagen and find out... ๐Ÿ˜œ
j
Ah, can't this year.. would love to though, but can't be in two places at once...
a
I don't want to spoil too much, because the pros and cons of SnapStart are definitely something I'll be covering. But I will say that if SnapStart causes no issues for your app, there's no reason not to enable it even for 100 ms.
๐ŸŽ‰ 2
@dave so there's actually some pretty drastic changes coming to the slides, but glad you like what you see so far. I'm actually not sure if I should be putting them in such an obvious place to spoil people, but I got excited ๐Ÿ˜…
I might get some "But what about"s for it, but I'm specifically ignoring Graal as a contender. Mostly due to lack of interest in the technology.
d
I like the chart, but not the scale. Itโ€™s neither linear nor log?
d
It might be worth putting graalvm in there as a data point if you have it, assuming that you didn't need to mess around too much (of course that in itself is potentially enough for a whole talk!). And assuming it doesn't obscure the point you're trying to make ๐Ÿ™ƒ
a
Yeah, the scale has been fudged so that everything fits better. Compounded by the new data points I've added since. I'll see if a proper logarithmic scale works ok. As for graal, I can see the benefit of including the data point, and I know people will ask about it. But I've been hesitant to talk about things I'm not familiar with. Maybe I'll try to get it to work. I know http4k has a guide dedicated to it.
If I'm going to add more data points, what I'll probably do is replace the handmade graph with a proper multi-series scatter plot or something.
j
Nice graphs!!
c
Curious hot Ktor would fit in your graph ๐Ÿ™‚
d
That's would be interesting. What's the recommended way to run ktor on aws lambda nowadays? Is it still kotless?
c
it's not a good fit i guess, ktor and aws-lambda. but then i'd say spring and aws-lambda is also not a good fit for the same reasons.
d
Well it is lightweight enough to be a reasonable fit if there was the technology to actually make it run.
It's just that the technology doesn't exist in order make it run (or at least something that is actively maintained). The advantage of being able to run your app anywhere is a laudable goal given the options of deployment which you can get without changing your underlying stack
a
Kotless used to exist to run ktor in Lambda, but it's been abandoned. I was working on an adapter, but lost interest in ktor ๐Ÿคท
๐Ÿ‘ 1
I suspect ktor would perform quite well if the right secondary dependencies are chosen