Exciting to see use cases pushing the limits of openwhisk and the proposal for UI and lower latency use cases.
A lot of points going on in this thread and assume more will be flushed out as well as the on the wiki page, wanted to add one more consideration the group should take into account, sorry if muddying the waters some. With the group efforts to port openwhisk to kubernetes this low latency/scale-out use case seems would be effected partially or greatly depending on how the implementation approach comes out. Anything that is dealing with spin up/scale-out/scale-down and generally scheduling of containers would be effected when running in kube or the like. In some cases the underlying orchestrator would provide some "batteries included" that openwhisk could possibly leverage or get "for free", such as something like kubernetes pod scaling using cpu or other whisk provided metrics for managing the pool of request handling containers: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale Anyways, didn't want to muddy the waters, figured as both kube support and this are in proposal stage, talk of making parts of openwhisk more pluggable for kube support could have an effect on this approach. It would be great if when both this and kube support are in one wouldn't have to run "native whisk" in order to take advantage of this proposal vs being able to run on the "kubernetes whisk" as well, but understand sometimes things happen in multiple stages of design and implementation Nate On Thu, Jul 6, 2017 at 1:00 PM, Dascalita Dragos <ddrag...@gmail.com> wrote: > > The prototype PR from Tyson was based on a fixed capacity of concurrent > activations per container. From that, I presume once the limit is reached, > the load balancer would roll over to allocate a new container. > +1. This is indeed the intent in this proposal. > > > a much higher level of complexity and traditional behavior than what you > described. > > Thanks for bringing up this point as well. IMO this also makes sense, and > it's not in conflict with the current proposal, but rather an addition to > it, for a later time. if OW doesn't monitor the activity at the action > container level, then it's going to be hard to ensure reliable resource > allocation across action containers. Based on my tests Memory is the only > parameter we can correctly allocate for Docker containers. For CPU, unless > "--cpu-set" is used, CPU is a shared resource across actions; one action > may impact other actions. For network, unless we implement custom network > drivers for containers, the bandwidth is shared between actions; one action > can congest the network, impacting other actions as well . Disk I/O, same > problem. > > So my point is that without monitoring, resource isolation (beyond memory) > remains theoretical at this point. > > In an ideal picture OW would monitor closely any available parameters when > invoking actions, through Tracing, monitoring containers, etc, anything > that's available. Then through machine learning OW can learn what's a > normal "SLA" for an action, maybe by simply learning the normal > distribution of response times, if CPU and other parameters are too much to > analyze. Then if the action doesn't behave normally for an Nth percentile, > take 2 courses of action: > 1) observe if the action has been impacted by other actions, and > re-schedule it on other VMs if that's the case. Today OW tries to achieve > some isolation through load balancer and invoker settings, but the rules > are not dynamic. > 2) otherwise, notify the developer that an anomaly is happening for one of > the actions > > These examples are out of the scope for the current proposal. I only shared > them so that we don't take monitoring out of the picture later. It's worth > a separate conversation on this DL, and it's not as pressing as the > performance topic is right now. > > Dragos > > > On Thu, Jul 6, 2017 at 4:40 AM Michael M Behrendt < > michaelbehre...@de.ibm.com> wrote: > > > thx for clarifying, very helpful. The approach you described could be > > really interesting. I was thrown off by Dragos' comment saying: > > > > "What stops Openwhisk to be smart in observing the response times, CPU > > consumption memory consumption of the running containers ? Doing so it > > could learn automatically how many concurrent requests 1 action can > > handle." > > > > ...which in my mind would have implied a much higher level of complexity > > and traditional behavior than what you described. > > > > Dragos, > > did I misinterpret you? > > > > > > > > Thanks & best regards > > Michael > > > > > > > > > > From: Rodric Rabbah <rod...@gmail.com> > > To: dev@openwhisk.apache.org > > Date: 07/06/2017 01:04 PM > > Subject: Re: Improving support for UI driven use cases > > > > > > > > The prototype PR from Tyson was based on a fixed capacity of concurrent > > activations per container. From that, I presume once the limit is > reached, > > the load balancer would roll over to allocate a new container. > > > > -r > > > > > On Jul 6, 2017, at 6:09 AM, Michael M Behrendt > > <michaelbehre...@de.ibm.com> wrote: > > > > > > Hi Michael, > > > > > > thx for checking. I wasn't referring to adding/removing VMs, but rather > > > activation contaIners. In today's model that is done intrinsically, > > while > > > I *think* in what Dragos described, the containers would have to be > > > monitored somehow so this new component can decide (based on > > > cpu/mem/io/etc load within the containers) when to add/remove > > containers. > > > > > > > > > Thanks & best regards > > > Michael > > > > > > > > > > > > >
