funker
funker copied to clipboard
bfirsh
Should functions serve more than one request?
The initial reason for this design was so that:
- They were completely fresh every time
- It was impossible to store state
- There was only one degree of scaling (throughput of tasks running == throughput of function calls)
- It just feels nice conceptually. task run == function call.
But, maybe this is a bit silly. The advantages of letting them be long-running is:
- They're easier to scale (less task churn, connections are queued on server side, etc)
- State can be stored if need be
- It's just less weird, really.
I think perhaps the function creator must assume the container is stateless/destroyed after each call. But as an optional optimisation you can keep the container running. Does that make sense? Not sure I've explained myself well...
I would ban storing of state - that should go somewhere else. Otherwise it gets tricky to migrate between nodes etc.
AWS Lambda functions last for 4 hours. Used to be 8. People do sometimes use this information, eg to cache stuff, save lookups if the function has been reused.
Yep, that makes sense. People will still store state, but we can build in a max number of requests into each function or something so people have to design around the fact that it will disappear. (i.e. it can only be a cache)
I'd just say you have to assume it can die at any moment. So put in a cache if you like, but make sure it works without it.
Sure you have to do that anyway, as you will still get a random container, and they will be created with nothing in regularly anyway.
Suggest random num reqs around a configurable mean.
That will smooth perf issues from mass restarts, and also make cache hits less predictable, which I guess is the aim.
I think @justincormack has a good point - RE: Lambda functions being technically stateful and lasting up to 4 hours. I've been running this on an ARM/Pi Swarm where the cost of creating a container is higher.
