Re: Performance findings on OpenWhisk

Thank you for the answer Rodric, now I clearly got what could be worse with that change other than file access. But I am still curious, how could you meet your target TPS. IIRC, though I create more stem cells, at maximum loads, container creation and deletion are inevitable. When docker daemon

Re: Possible enhancements around attachment handling

> This should be absolutely doable without a change in the runtimes at all, as > they "shouldn't" (to be verified) need a change to support TCP streaming. I think some of the runtimes are currently reading whole request in memory. For e.g. in Java [1] it constructs a json instance. So would need

Re: Deploying OpenWhisk in Cloud: do we need Kubernetes?

Michele Sciabarra wrote on 03/28/2018 08:52:04 AM: > > Ok , so you are saying that Kubernetes make it easy to deploy OpenWhisk. > Then we should really provide an helm chart, I think. > Because it is the de-facto packaging for Kubernetes nowadays. > > And contribute it

Re: Possible enhancements around attachment handling

Heya, >> So for #C is there a way to proxy the stream without changing the runtime >> http api where binary is passed embedded in the json object on /init? > They would need to be modified. A less intrusive approach would have > been to pass signed url and use client like wget to fetch the

Re: Performance findings on OpenWhisk

Thanks for the detailed post. Indeed as you’ve observed the container scheduler is why openwhisk is different from other faas out there which delegate to a container manager. Your approach of reusing a container across tenants could be achieved by creating more stem cells. In a typical