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 <[email protected]> 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
