mirror of
https://github.com/fnproject/fn.git
synced 2022-10-28 21:29:17 +03:00
9edacae928
this patch gets rid of max concurrency for functions altogether, as discussed, since it will be challenging to support across functions nodes. as a result of doing so, the previous version of functions would fall over when offered 1000 functions, so there was some work needed in order to push this through. further work is necessary as docker basically falls over when trying to start enough containers at the same time, and with this patch essentially every function can scale infinitely. it seems like we could add some kind of adaptive restrictions based on task run length and configured wait time so that fast running functions will line up to run in a hot container instead of them all creating new hot containers. this patch takes a first cut at whacking out some of the insanity that was the previous concurrency model, which was problematic in that it limited concurrency significantly across all functions since every task went through the same unbuffered channel, which could create blocking issues for all functions if the channel is not picked off fast enough (it's not apparent that this was impossible in the previous implementation). in any event, each request has a goroutine already, there's no reason not to use it. not too hard to wrap a map in a lock, not sure what the benefits were (added insanity?) in effect this is marginally easier to understand and less insane (marginally). after getting rid of max c this adds a blocking mechanism for the first invocation of any function so that all other hot functions will wait on the first one to finish to avoid a herd issue (was making docker die...) -- this could be slightly improved, but works in a pinch. reduced some memory usage by having redundant maps of htfnsvr's and task.Requests (by a factor of 2!). cleaned up some of the protocol stuff, need to clean this up further. anyway, it's a first cut. have another patch that rewrites all of it but was getting into rabbit hole territory, would be happy to oblige if anybody else has problems understanding this rat's nest of channels. there is a good bit of work left to make this prod ready (regardless of removing max c). a warning that this will break the db schemas, didn't put the effort in to add migration stuff since this isn't deployed anywhere in prod... TODO need to clean out the htfnmgr bucket with LRU TODO need to clean up runner interface TODO need to unify the task running paths across protocols TODO need to move the ram checking stuff into worker for noted reasons TODO need better elasticity of hot f(x) containers
112 lines
2.9 KiB
Markdown
112 lines
2.9 KiB
Markdown
# Hot functions
|
|
|
|
Oracle Functions is built on top of container technologies, for each incoming
|
|
workload, it spins a new container, feed it with the payload and sends the
|
|
answer back to the caller. You can expect an average start time of 300ms per
|
|
container. You may refer to [this blog](https://medium.com/travis-on-docker/the-overhead-of-docker-run-f2f06d47c9f3#.96tj75ugb) post to understand the details better.
|
|
|
|
In the case you need faster start times for your function, you may use a hot
|
|
container instead.
|
|
|
|
hot functions are started once and kept alive while there is incoming workload.
|
|
Thus, it means that once you decide to use a hot function, you must be able to
|
|
tell the moment it should reading from standard input to start writing to
|
|
standard output.
|
|
|
|
Currently, Functions implements a HTTP-like protocol to operate hot
|
|
containers, but instead of communication through a TCP/IP port, it uses standard
|
|
input/output.
|
|
|
|
## Implementing a hot function
|
|
|
|
In the [examples directory](https://github.com/treeder/functions/blob/master/examples/hotfunctions/http/func.go), there is one simple implementation of a hot function
|
|
which we are going to get in the details here.
|
|
|
|
The basic cycle comprises three steps: read standard input up to a previosly
|
|
known point, process the work, the write the output to stdout with some
|
|
information about when functions daemon should stop reading from stdout.
|
|
|
|
In the case at hand, we serve a loop, whose first part is plugging stdin to a
|
|
HTTP request parser:
|
|
|
|
```go
|
|
r := bufio.NewReader(os.Stdin)
|
|
req, err := http.ReadRequest(r)
|
|
|
|
// ...
|
|
} else {
|
|
l, _ := strconv.Atoi(req.Header.Get("Content-Length"))
|
|
p := make([]byte, l)
|
|
r.Read(p)
|
|
}
|
|
```
|
|
|
|
Note how `Content-Length` is used to help determinate how far standard input
|
|
must be read.
|
|
|
|
The next step in the cycle is to do some processing:
|
|
|
|
```go
|
|
//...
|
|
var buf bytes.Buffer
|
|
fmt.Fprintf(&buf, "Hello %s\n", p)
|
|
for k, vs := range req.Header {
|
|
fmt.Fprintf(&buf, "ENV: %s %#v\n", k, vs)
|
|
}
|
|
//...
|
|
```
|
|
|
|
And finally, we return the result with a `Content-Length` header, so
|
|
Functions daemon would know when to stop reading the gotten response.
|
|
|
|
```go
|
|
res := http.Response{
|
|
Proto: "HTTP/1.1",
|
|
ProtoMajor: 1,
|
|
ProtoMinor: 1,
|
|
StatusCode: 200,
|
|
Status: "OK",
|
|
}
|
|
res.Body = ioutil.NopCloser(&buf)
|
|
res.ContentLength = int64(buf.Len())
|
|
res.Write(os.Stdout)
|
|
```
|
|
|
|
Rinse and repeat for each incoming workload.
|
|
|
|
|
|
## Enabling a hot function
|
|
|
|
In your func.yaml, add "format: http". That's it.
|
|
|
|
|
|
|
|
<!--
|
|
|
|
Once your functions is adapted to be handled as hot function, you must tell
|
|
Functions daemon that this function is now ready to be reused across
|
|
requests:
|
|
|
|
```json
|
|
{
|
|
"route":{
|
|
"app_name": "myapp",
|
|
"path": "/hot",
|
|
"image": "USERNAME/hchttp",
|
|
"memory": 64,
|
|
"type": "sync",
|
|
"config": null,
|
|
"format": "http",
|
|
"idle_timeout": 30
|
|
}
|
|
}
|
|
```
|
|
-->
|
|
|
|
|
|
`format` (mandatory) either "default" or "http". If "http", then it is a hot
|
|
container.
|
|
|
|
`idle_timeout` (optional) - idle timeout (in seconds) before function termination.
|
|
|