Closed emschwartz closed 5 years ago
Actually it would be worth looking into whether the performance is better with each lambda function handling a single incoming ILP packet or having the receiver be longer-lived. The expected use case is that a lot of packets will come in for the same receiver within a relatively short period of time. I wonder whether the overhead of starting up the lambda function would outweigh the performance benefits, or whether the flexibility and easy scaling would make it worth it.
Actually it would be worth looking into whether the performance is better with each lambda function handling a single incoming ILP packet or having the receiver be longer-lived.
I believe there are some work-arounds to prevent cold starts by calling all lambda functions periodically from a separate scheduled lambda function. This mitigates the response time from a ~5 second cold start to something more tolerable.
This is really interesting. Yeah in regards to cold starts you can warm up the lambda function beforehand with something that hits it with an http/https request. Although I’m not sure how lambda functions deal with concurrent requests. If you warm up one, would the others cold start?
Thinking about it more, the cold start shouldn't be a problem because the same lambda function can handle incoming packets for different STREAM connections. It wouldn't need to wake them up and put them to sleep for every packet.
I don't think a lambda function is a good idea after all. However, I did switch the stream receiver to be stateless and the whole architecture is now oriented around a simpler request/response pattern
It would be cool to make a deconstructed SPSP / STREAM receiver designed for AWS Lambda (using the new Rust runtime).
To build this we would need:
Other notes: