> 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 <tnor...@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 <rod...@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
