61–70 of 233 posts
It keeps 1 instance running at all times, and for the most part completely gets rid of cold starts. You have to pay a small cost each month (a few dollars), but its worth it on valuable functions that result in conversions, e.g. loading a Stripe checkout.
The 128M case is really strange, why do Go and Rust take so much more time to start than higher-capacity machines, and even Python? Do they get run inside a wasm runtime or something, and that runtime has to go back and forth requesting memory which a native python runtime gets “for free”?
For Rust, I suspect spinning up Tokio and the rest of async runtime might be making cold starts worse. But that's purely speculation. The python lambda is good old-fashioned sync io.
Another difference is that Rust lambda initializes a logger, while Python one doesn't. That might add some milliseconds too to the startup.
Earlier quoted context omitted.
Great tip for running the JIT AOT, for anyone interested Microsoft calls this "ReadyToRun" compilation [1]. [1] https://docs.microsoft.com/en-us/dotnet/core/deploying/ready... I wonder did you test if the increased size results in an actual win for the startup time ?
and then you need to upgrade the plan because it is disk/memory hungry and doesn't fit within the 128mb plan, so you'll pay 4x more already just use GO and be faster while saving money at the same time
If anyone is running into cold start problems on Firebase, I recently discovered you can add .runWith({minInstances: 1}) to your cloud functions. It keeps 1 instance running at all times, and for the most part completely gets rid of cold starts. You have to pay a small cost each month (a few dollars), but its worth it on valuable functions that result in conversions, e.g. loading a Stripe checkout.
At my last job we built an entire API on top of serverless. One of the things we had to figure out was this cold start time. If a user were to hit an endpoint for the first time, it would take 2x as long as it normally would at first. To combat this we wrote a "runWarm" function that kept the API alive at all times. Sure kind of defeats the purpose of serverless but hey, enterprise software.
I can't explain to my coworkers, they wouldn't understand.
Earlier quoted context omitted.
It makes Lambda look like a product with a much narrower niche than what AWS wants to sell it as. For many people knowing beforehand that cold start times are > 500ms with 256MB (quite extravagant for serving a single web request) would disqualify Lambda for any customer-serving endpoint. As it stands many get tricked into that choice if they don't perform these tests themselves.
In my experience, if you can't say "get over it" to your customers when they complain about performance then Lambda is not the right tool. Just use EC2.
Earlier quoted context omitted.
Provisioned concurrency is insanely expensive. If you have any kind of a thundering herd access pattern then Lambda is a complete non-starter because of the warm-up and scaling characteristics. We eventually just put an nginx/openresty server on a regular medium EC2 instance and got rid of Lambda from our stack completely and now we're paying about 1/300th the cost we were previously and the performance is infinitely…
This is another example of AWS over marketing Lambda. Lambda is horrendously expensive when requests pass a certain level per second. You can graph it against ECS / EC2 to see the point it stops becoming economical. Taking all of this into account, Lambda is then useful for a very small niche: - Tasks that don't care about low P99 latency. These tend to be asynchronous processing workflows, as APIs in the customer re…
My experience with cold starts in Azure Functions Serverless is pretty awful. Like most other Azure services, their affordable consumer grade offerings are designed from the ground up not to be good enough for "serious" use. Cold start times compared to Lambda are worse, and in addition, we would get random 404s which do not appear in any logs; inspecting these 404s indicated they were emitted by nginx, leading me to…
Cool article, but shouldn’t Amazon be providing this kind of info? Surely they have this data internally.
1 - Hey, $SERVICE looks exactly what I need. Neat!
2 - Wait, how do I do $THING with $SERVICE. No way $SERVICE can't do $THING.
3 - Realize $SERVICE is extremely limited and full of weird edge cases, get pissed.
In general their docs are not transparent about the limitations of their products compared to similar non managed solutions.
I sort of gave up using AWS managed services after a few years DevOpsing, except for the more flexible / battle tested ones: VPC, EC2, etc...