Comment by freecodyx | Hacker News Reader

Comment by freecodyx | Hacker News Reader

""" The Go runtime's timer and deadline code is faster and scales better with higher numbers of CPUs. In particular, this improves the performance of manipulating network connection deadlines. """

I hope so, i was testing running a service as a lambda function in AWS,

I am using time.NewTicker()/time.After() and co to control go routines behaviour (via channels).

To my surprise, this is not behaving well in lambda, many times, a Ticker configured for 1 second for example, will tick after 12 sec, sometimes even 200sec, it's not consistent at all.

When i increase the memory allocated to the lambda function (which will increase the number of cpu) it behaves better.

It's a large service with millions of call per day. i don't know if this was related to the GC stopTheWorld, Or something is wrong with lambda runtime.

AIUI, Lambda operates on requests. (Either "calls" to a function, i.e., just invoking a lambda function w/ args and getting the result over the network somewhere else, or as an HTTP handler or a CloudWatch handler, but those are really specialized cases of the first.) Using time.NewTicker/time.After strikes me as something you would do to maintain some sort of background process, which Lambda is not intended for: IIRC, Lambda can arbitrarily freeze your process b/c no requests are being served presently, and that "capacity" isn't needed as far as AWS is concerned. I think under the hood they're doing a cgroup freezer or something, but the result would be exactly what you see: timers firing way too late. They wouldn't fire until the underlying container is unfrozen. This wouldn't be a bug in Go or Lambda; Lambda is specifically designed to do this, so as to free you from needing to care about how much capacity you require¹. (At the cost of making stuff like background timers not work; that's not its model.)

See: https://aws.amazon.com/blogs/compute/container-reuse-in-lamb...

¹ish. take that statement w/ a grain of salt.

Well, this is the issue, when my function exceeds the timeout configured in the function yml, lambda will respond with internal server error, and will freeze the VM, if it decides to reuse the VM for another request, then the go-routines of the last call will resume (because i didn't call os.Exit).

This sounds like an amazing pain in the ass. I wonder if this impacts my own lambdas.

please do, and let us know

Reply on news.ycombinator.com