openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyson Norris <tnor...@adobe.com.INVALID>
Subject Re: Improving support for UI driven use cases
Date Sat, 01 Jul 2017 22:18:37 GMT

> On Jul 1, 2017, at 1:51 PM, Rodric Rabbah <rodric@gmail.com> wrote:
> 
> 
>> it is quite common, for example to run nodejs applications that happily serve hundreds
or thousands of concurrent users, 
> 
> I can see opportunities for treating certain actions as intrinsic for which this kind
of gain can be realized. Specifically actions which are performing network operations then
computing on the result. One can split the asynchronous io, and pack it into a more granular
concurrency engine. Intuitively, I think it's more likely to benefit this way and protect
against concurrency bugs and the like but using higher level action primitives.
> 
> -r

I’m not sure what you’re getting at - are you suggesting splitting the network operations
out and running them “not as actions” or “separate from compute portion of the action"?
I’m sure that would be possible, but it would seem like diminished returns in complexity
for 90% of cases where “computing on the result” is lightweight compared to the waiting
for IO completion, I’m not sure it would be worth it to force developers down a path of
configuring actions based on the network ops of the code within, compared to simply allowing
concurrency. 

Thanks
Tyson

Mime
View raw message