openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Glikson" <GLIK...@il.ibm.com>
Subject Re: Improving support for UI driven use cases
Date Sat, 01 Jul 2017 21:07:45 GMT
> a burst of users will quickly exhaust the system, which is only fine for 
event handling cases, and not fine at all for UI use cases.

Can you explain why is it fine for event handling cases?
I would assume that the key criteria would be, for example, around 
throughput and/or latency (and their tradeoff with capacity), and not 
necessarily the nature of the application per se.

Regards,
Alex



From:   Tyson Norris <tnorris@adobe.com.INVALID>
To:     "dev@openwhisk.apache.org" <dev@openwhisk.apache.org>
Date:   01/07/2017 10:18 PM
Subject:        Re: Improving support for UI driven use cases



Sure - what I mean is that once N containers are launched, and servicing N 
activations, the N+1th activation is queued and processed sequential to 
some particular one of the previous activations. And N is directly related 
to concurrent users (and actions), so a burst of users will quickly 
exhaust the system, which is only fine for event handling cases, and not 
fine at all for UI use cases. 

So ?sequential? is not quite accurate, but once concurrent activations max 
out the container pool, it behaves as a queue compared to a system that 
concurrently processed activations in a single container - which will have 
its own point of exhaustion admittedly, but I think it is quite common, 
for example to run nodejs applications that happily serve hundreds or 
thousands of concurrent users, so we are taking about adding orders of 
magnitude to the number of concurrent users that can be handled using the 
same pool of resources. 

Thanks
Tyson




> On Jul 1, 2017, at 11:41 AM, Rodric Rabbah <rodric@gmail.com> wrote:
> 
>> the concurrency issue is currently entangled with the controller
> discussion, because sequential processing is enforced
> 
> how so? if you invoke N actions they don't run sequentially - each is 
its
> own activation, unless you actually invokes a sequence. Can you clarify
> this point?
> 
> -r






Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message