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
fnlb-test-harness
Test harness that exercises the fnlb load balancer in order to verify that it works properly.
How it works
This is a test harness that makes calls to an Oracle Functions route through the fnlb load balancer, which routes traffic to multiple Oracle Functions nodes. The test harness keeps track of which node each request was routed to so we can assess how the requests are being distributed across the nodes. The functionality of fnlb is to normally route traffic to the same small number of nodes so that efficiences can be achieved and to support reuse of hot functions.
Primes function
The test harness utilizes the "primes" function, which calculates prime numbers as an excuse for consuming CPU resources. The function is invoked as follows:
curl http://host:8080/r/primesapp/primes?max=1000000&loops=1
where:
- max: calculate all primes <= max (increasing max will increase memory usage, due to the Sieve of Eratosthenes algorithm)
- loops: number of times to calculate the primes (repeating the count consumes additional CPU without consuming additional memory)
How to use it
The test harness requires running one or more Oracle Functions nodes and one instance of fnlb. The list of nodes must be provided both to fnlb and to the test harness because the test harness must call each node directly one time in order to discover the node's container id.
After it has run, examine the results to see how the requests were distributed across the nodes.
How to run it locally
Each of the Oracle Functions nodes needs to connect to the same database.
STEP 1: Create a route for the primes function. Example:
fn apps create primesapp
fn routes create primesapp /primes jconning/primes:0.0.1
STEP 2: Run five Oracle Functions nodes locally. Example (runs five nodes in the background using Docker):
sudo docker run -d -it --name functions-8082 --privileged -v ${HOME}/data-8082:/app/data -p 8082:8080 -e "DB_URL=postgres://dbUser:dbPassword@dbHost:5432/dbName" treeder/functions
sudo docker run -d -it --name functions-8083 --privileged -v ${HOME}/data-8083:/app/data -p 8083:8080 -e "DB_URL=postgres://dbUser:dbPassword@dbHost:5432/dbName" treeder/functions
sudo docker run -d -it --name functions-8084 --privileged -v ${HOME}/data-8084:/app/data -p 8084:8080 -e "DB_URL=postgres://dbUser:dbPassword@dbHost:5432/dbName" treeder/functions
sudo docker run -d -it --name functions-8085 --privileged -v ${HOME}/data-8085:/app/data -p 8085:8080 -e "DB_URL=postgres://dbUser:dbPassword@dbHost:5432/dbName" treeder/functions
sudo docker run -d -it --name functions-8086 --privileged -v ${HOME}/data-8086:/app/data -p 8086:8080 -e "DB_URL=postgres://dbUser:dbPassword@dbHost:5432/dbName" treeder/functions
STEP 3: Run fnlb locally. Example (runs fnlb on the default port 8081):
fnlb -nodes localhost:8082,localhost:8083,localhost:8084,localhost:8085,localhost:8086
STEP 4: Run the test harness. Note that the 'nodes' parameter should be the same that was used with fnlb. Example:
cd functions/test/fnlb-test-harness
go run main.go -nodes localhost:8082,localhost:8083,localhost:8084,localhost:8085,localhost:8086 -calls 10 -v
STEP 5: Examine the output to determine how many times fnlb called each node. Assess whether it is working properly.
Usage
go run main.go -help
Command line parameters:
- -calls: number of times to call the route (default 100)
- -lb: host and port of load balancer (default "localhost:8081")
- -loops: number of times to execute the primes calculation (ex: '-loops 2' means run the primes calculation twice) (default 1)
- -max: maximum number to search for primes (higher number consumes more memory) (default 1000000)
- -nodes: comma-delimited list of nodes (host:port) balanced by the load balancer (needed to discover container id of each) (default "localhost:8080")
- -route: path representing the route to the primes function (default "/r/primesapp/primes")
- -v: flag indicating verbose output
Examples: quick vs long running
Quick function:: calculate primes up to 1000
go run main.go -nodes localhost:8082,localhost:8083,localhost:8084,localhost:8085,localhost:8086 -max 1000 -v
where -max is default of 1M, -calls is default of 100, -route is default of "/r/primesapp/primes", -lb is default localhost:8081
Normal function: calculate primes up to 1M
go run main.go -nodes localhost:8082,localhost:8083,localhost:8084,localhost:8085,localhost:8086 -v
where -max is default of 1M, -calls is default of 100, -route is default of "/r/primesapp/primes", -lb is default localhost:8081
Longer running function: calculate primes up to 1M and perform the calculation ten times
go run main.go -nodes localhost:8082,localhost:8083,localhost:8084,localhost:8085,localhost:8086 -loops 10 -v
where -max is default of 1M, -calls is default of 100, -route is default of "/r/primesapp/primes", -lb is default localhost:8081
1000 calls to the route: send 1000 requests through the load balancer
go run main.go -nodes localhost:8082,localhost:8083,localhost:8084,localhost:8085,localhost:8086 -calls 1000 -v
where -max is default of 1M, -calls is default of 100, -route is default of "/r/primesapp/primes", -lb is default localhost:8081
Planned Enhancements
- Create 1000 routes and distribute calls amongst them.
- Use concurrent programming to enable the test harness to call multiple routes at the same time.