A modern programming language that makes developers happier.

kotlinlang

Untitled.png

After upgrading to Kotlin 2.0, Jetty to Jetty Loom, and aws sdk v2 to http4k-connect :sad-panda:

Worth doing one at a time so see the difference? I presume this is jetty loom really. Would also be interesting to see the stats for the client calls. :upside_down_face: 

image.png

Ok, so there was actually an issue with my SQS poller after the http4k-connect upgrade which caused a massive busy-wait loop, which had an effect on overall request performance.  After rolling back and then fixing the underlying problem, the new stack is just as fast as, if not better than, the baseline.

Don't mind the small spike.  I don't have a great solution for pre-warming ECS containers.

let this be a lesson to release in smaller increments! :wink: 

<@U01V2S2HGRK> We (not using http4k yet) simply have some new thread throw a few requests at the server (trying to touch a small but diverse set of endpoints) as one of the lasts steps of application boot. This because the CPU spike when auto-scaling up the cluster made the app unresponsive to some users. Works like a charm.

Yeah, seems reasonable.  Do you ensure these requests 200?  Or can they 404?

Is the purpose of these requests just to set up database connection pools or is there something else that I'm missing,. TBH for this type of thing we've tended to put these into a composite health check endpoint - so you'll get one to make sure you can talk to the DB, one for talking to SQS etc. This also means that you can get a very granular report about if various probes are up/down

I've never debugged why exactly my ECS cold starts tend to be so bad, but I suspect connection pools, JIT compilation, and the fraction of a vCPU I tend to allocate are the culprits.

A "useful" health check is probably most ideal for pre-warming the container, but it's always something I neglect :sweat_smile:

I even had one of these for a service once, but I got little use out of it, and didn't feel like I could justify the extra code to test the different dependencies without known resource IDs.

<@U01V2S2HGRK> "Do you ensure these requests 200? Or can they 404?" Mostly we want 200s so we check for that and show an error or warning in the logs if not. If you want to warm up error page rendering as well, you may want to trigger errors too! I'm not sure if I understand the JVM well enough, but I simply try to pick enpoints that make sure a lot of code paths have been used. So I want it to hit the db, use the templating lib XYZ, use the PDF/XLS/etc renderers, do some JSON rendering. We found that the first "real" requests were significantly faster after running our basic warm up script.