Hacker News Reader

Comment by adamgordonbell | Hacker News Reader

Author here. I didn't expect this to show up here. I found containers on lambda to work really well. I can easily test them locally and they scale to zero when I'm not using them in AWS. So it's perfect for things that are idle a lot.

I have a follow up coming where I use go in a container, and the request speed got a lot better.

The service in this article is my html to text convert, so having a container where I could install OS-dependencies was crucial to getting this working. It's covered here and here:

https://news.ycombinator.com/item?id=30829568

https://earthly-tools.com/text-mode

View on HN

> I have a follow up coming where I use go in a container, and the request speed got a lot better.

My team transitioned a lightweight python based lambda from zip to container based and we also saw a small (but definitely real) speedup in request time. I'm not the one who did the benchmarking, but iirc it was about 10ms faster. From ~50ms to ~40ms or so.

edit: originally phrased it backwards to seem like container method was slower.

Are you saying latency is lower on container than plain python?

I recently made a project for the company and didn't even consider containers (which I love btw) because I though I could save some ms without container.

Do you know if lambda containers performance is also good in nodejs? I need to have python and nodejs lambdas.

Versus the .zip file deploy method if that's what you mean, yes the container had a lower latency. The core code didn't change. This is just for the response time on a warmed-up lambda. We didn't benchmark cold-start times, but just from using it the cold-starts don't seem noticeably worse (Maybe they're also better? Honestly I don't know).

Sorry don't know about nodejs yet. This was for a new lambda that wasn't in production yet, so it made sense to experiment.

The increase in speed was unexpected but nice. But we're also assuming this increase is a static ~10ms speedup, and not a 20% speedup, but we only tested one lambda. I'm interested to see Adam's followup post and see if I'm wrong about that.

Oh also just want to say, since the workings of lambda are hidden, it could be some totally different reason why containers perform better. Since its a newer feature, maybe it's running a newer version of the backend that the zip file backend will be moved to. Maybe container-based lambdas are allocated on newer hardware. Maybe containers are actually just faster. Can't ever really know without getting hired by Amazon and signing an NDA, lol.

Someone here recently said that the Lambda Python runtime is not stock Python (apparently it's compiled without optimisations: https://news.ycombinator.com/item?id=30953202) - maybe that has something to do with it?

It definitely could, we are talking in the order of ~10ms, even the version of python over the years can mean such improvement (or better depending on the code of course).

I was interested on the cold starts though. I will have to experiment in the future.

My experience has been the opposite, with simple python docker containers showing noticeably slower cold starts than python zips. I've also found the size of the zip package matters (smaller is faster). However things change over time, maybe there have been recent improvements?

Specifically regarding cold starts of lambda instances, I recall this excellent article from Jan 2021 which measures cold start latencies for a variety of AWS lambda runtimes:

https://mikhail.io/serverless/coldstarts/aws/languages/

I would love to see a 2022 update.

Our benchmarking was only for a to a warmed lambda, I don't believe any language can do a 50ms cold start on lambda. The fastest example in your link is python with around 150ms cold start as the fastest, and that's an outlier from the average.

Reply on news.ycombinator.com