interledger / interledger-rs

An easy-to-use, high-performance Interledger implementation written in Rust
http://interledger.rs
Other
201 stars 70 forks source link

SPSP / STREAM Server Lambda Function #25

Closed emschwartz closed 5 years ago

emschwartz commented 5 years ago

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:

emschwartz commented 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.

ekrenzke commented 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.

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.

dino-rodriguez commented 5 years ago

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?

emschwartz commented 5 years ago

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.

emschwartz commented 5 years ago

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