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

Reply via email to