functions
functions copied to clipboard
iron-io
Streaming Input and Hot Containers
The idea here is to allowing a streaming input format to allow multiple requests per single container execution. The reason for this is to provide very fast responses to synchronous requests.
The problem is that there is a lot of startup/teardown overhead when starting a function/container.
- Docker itself adds a lot of overhead in the order of 300-1000ms per execution.
rktis 2-3x slower than Docker from our tests, see #195. - The language itself may have startup/teardown overhead like Java starting the JVM and Ruby loading gems.
- The code may have overhead such as making connections to databases.
All of those are stacked too, so add all of them up and add that to the execution time of the actual function code.
With streaming input, the first function call will be slow, while the rest (until the container is terminated) will be very fast.
Prior discussion in #72
Why not use the FastCGI protocol for this? It's an industry standard protocol with existing client libraries for almost any runtime one could hope for.
Hi @japsu - thanks for the suggestion. All options are on the table right now, including FastCGI. We should definitely consider it.
Moved to Beta1. TODO:
- JSON-HTTP protocol
- Add more examples in other programming languages
fyi implementation of this would be no brainer (basically simple forwarding), if implementations talked with http through standard tcp port: #520
by using http through stdio you burden yourselves with translation between tcp and stdin/stdout
I hereby rescind my above comment about FastCGI.
FastCGI has been superseded by proxying ordinary HTTP requests almost everywhere.
@sheerun's proposal of using HTTP over a standard port is superior. It requires no special SDK, client library or proprietary protocol support and it provides the easiest possible upgrade path from traditional applications to serverless.
While not as trivial re: library support, ordinary HTTP can also be done over UNIX domain sockets.
gRPC seems to be on its way to becoming the defacto standard for server side communication when people care about perf and want something cross platform. Considering that the sole reason for introducing this is perf... why not gRPC?
