Hacker News Reader

Comment by mrtksn | Hacker News Reader

That’s great news. For some reason cloud function run extremely slowly for me on Firebase. Like a few seconds slow on the first call if not called frequently, then it drops to milliseconds level.

View on HN

That's by design. Your server 'sleeps' and

- wakes up on for a request(few seconds delay on request),

- stays awake (requests are fast here),

- goes back to sleeping if idle for sometime (15mins?)

This is what keeps the costs low (or free). Same is true for Heroku, Lambda, Vercel, Azure Functions, etc.

Sure but it is not an acceptable level of latency when the product is supposed to respond on user input. When the app or the feature is new or obscure it would fall in this state all the time.

Last time I checked I wasn’t renting a server, it was supposed to be a service that’s fast at any scale.

A 5$ DO instance would provide much better experience. They should give an option to keep it awake albeit at a cost.

Azure functions has that option, but at some point... Why not just use a "real" web server if you want it always online? The whole point of serverless was that you don't need a server always running in the background.

Lambda also provides this functionality — they call it "provisioned concurrency": https://docs.aws.amazon.com/lambda/latest/dg/configuration-c...

I don’t want to deal with it until it’s worth dealing with it. That is, until the cost of managing a server and it’s integration is less than the cost of using Firebase(which comes with free integration and no management needs).

The easiest way around it is to keep ping-ing it every 5 mins from either from a third party (like pingdom, uptimerobot.com) or a cron function (https://cloud.google.com/scheduler/docs/creating).

But I would recommend using Cloud Run instead.

Isn't Cloud Run's cold start latency even worse?

Actually you are right. I was under the impression that we can define minimum-maximum instances to run. But apparently it scales down to zero and there is no way to prevent that.

Pinging a Lambda is the blind leading the blind. Your Lambda still gets periodically shut down and you still have cold starts! To avoid cold start, don’t use Lambda!

Cloud functions are not a good option for low traffic services where you'd like to have good latency.

Cloudflare Workers are probably the best option in terms of cold starts and latency but are much more limited than other services.

To reduce cold-start latency in AWS Lambda, use "Provisioned Concurrency": https://aws.amazon.com/blogs/aws/new-provisioned-concurrency...

Yes, but I usually run my lambda function in multiple regions

This gives user low latency if the service is being used

If I've to launch DO server in 10 region, it will cost me $50 even if I am receiving a few request per day.

Yeah, this is called a 'startup effect' in most cloud function environments. Lambda has a thing called 'prewarming' which basically hits it every 15ish seconds to make sure it's still active...

I am considering to implement something like that by myself. It’s not an acceptable performance otherwise. Alternatively I am looking into running it on different tech, I would have moved already on Swift on Linux if Fireplace had a library for Swift beyond iOS.

Does it really sleep in 15 seconds such that it needs to warm up? Why call it every 15 seconds? Why not every hour, every day? Is there a documentation how often it needs a warm-up?

I believe AWS docs say that your function is loaded on a machine for 15 seconds after termination... so if a new request comes in during that time it goes to that function instead of starting a new one.

Lambda has provisioned capacity now. You can just tell it how many to keep warm and it'll keep that many warm (but still cold start additionally as necessary).

Reply on news.ycombinator.com