Another (I would say easy) win for actionloop is Swift. Numbers just tested:
Current one: *** Testing openwhisk/action-swift-v4.1 *** Running 10s test @ http://localhost:8080/run 1 threads and 1 connections Thread Stats Avg Stdev Max +/- Stdev Latency 11.93ms 4.42ms 86.72ms 98.50% Req/Sec 85.72 9.85 101.00 87.00% 859 requests in 10.05s, 116.60KB read Requests/sec: 85.51 Transfer/sec: 11.61KB The new one you have the PR to merge: *** Testing msciab/actionloop-swift-v4.2.1 *** Running 10s test @ http://localhost:8080/run 1 threads and 1 connections Thread Stats Avg Stdev Max +/- Stdev Latency 14.15ms 66.82ms 529.16ms 95.77% Req/Sec 1.04k 151.90 1.21k 88.54% 9935 requests in 10.01s, 1.28MB read Requests/sec: 992.40 Transfer/sec: 130.83KB -- Michele Sciabarra mich...@sciabarra.com ----- Original message ----- From: Carlos Santana <csantan...@gmail.com> To: dev@openwhisk.apache.org Subject: Re: Submitted PR for performance boost of the Go Runtime Date: Wed, 28 Nov 2018 09:20:21 -0500 Thanks Michele for looking into this The numbers look great ! I will review the PR soon -- Carlos On Wed, Nov 28, 2018 at 5:25 AM Michele Sciabarra <mich...@sciabarra.com> wrote: > Hello all, > > after the first embarrassing numbers of the Golang runtime that made me > hurry to fix performances :)), here I provide the updated numbers of > action-loop based runtimes compared with the current ones. Those numbers > can vary slightly from one run to another (for example I discovered it > depends how charged is your Mac) but generally are proportional when > running in the same environment. > > I just run the benchmarks, and I have: > > Performance report > *** actionloop-golang-v1.11 (improved) > Requests/sec: 1086.67 > Transfer/sec: 154.93KB > *** nodejs6action > Requests/sec: 1006.41 > Transfer/sec: 225.07KB > *** actionloop-nodejs6action > Requests/sec: 1230.92 > Transfer/sec: 157.09KB > *** python3action > Requests/sec: 20.05 > Transfer/sec: 2.62KB > *** actionloop-python > Requests/sec: 1066.84 > Transfer/sec: 139.61KB > > Note the actionloop runtimes are really prototypes, I have not run any > test suite against them. > > -- > Michele Sciabarra > mich...@sciabarra.com > > ----- Original message ----- > From: Michele Sciabarra <mich...@sciabarra.com> > To: dev@openwhisk.apache.org > Subject: Submitted PR for performance boost of the Go Runtime > Date: Tue, 27 Nov 2018 23:38:11 +0100 > > I just submitted a PR to improve performances of the Go/ActionLoop runtime > while being the less invasive possible. > > I am keeping the current design and I have not changed approach: there is > still child process fed by the HTTP server on standard input with output on > file descriptor 3. I am still using the standard http server (not the fast > HTTP server). > On the converse, I removed all the goroutines. They do not play well with > external processes. Instead, I am using the classical technique of > suspending on reading the standard input is fast to commute to the child > process/ > > I reached in my tests around 1150 requests/second (a bit worse than the > nodejs but I think decent). > It is possible to further improve performances up to 1500 but I need to > abandon the actionloop model and run an action with an independent server, > so for now I am not doing anything like this, > > -- > Michele Sciabarra > mich...@sciabarra.com > -- Carlos Santana <csantan...@gmail.com>