On Wed, Apr 28, 2021 at 12:57 AM Piotr Morgwai Kotarbinski <
morg...@gmail.com> wrote:

> I was surprised actually, because I thought parallel request message
> processing was a common use-case, both for gRPC and websockets
>

Yeah, we call those "RPCs." They can scale very wide horizontally.

(for example if we have a service that does some single-threaded graphic
> processing on received images and sends back a modified version of a given
> image, it would be most efficient to dispatch the processing to a thread
> pool with a size corresponding to available CPU/GPU cores, right? As
> processing them sequentially would utilize just 1 core per request stream,
> so in case of low number of concurrent request streams, we would be
> underutilizing the cores).
>

What's more rare is to have in-order processing (using a stream) that *can* be
split to multiple threads, as in-order and multi-threaded tend to be
at-odds. If you are just processing images, then you can commonly process
them each individually and would use separate RPCs. For
in-order+multi-threaded, you need to cut up the input data in a
server-specific way (e.g., I-frame frequency for video encoding), do
heavy-lifting in a thread-for-each-chunk, and then recombine in the end.
(If it isn't server-specific, the client is more likely to do the cutting.)
The cutting and merging easily become application-specific. Although your
tool would probably help many cases even with application-specific logic,
it's just not a common enough case for us to have utilities on hand. I
think I've seen most of such cases show up in server→client processing,
like pubsub, where the server is actually sending work to the client yet
can't "just do another RPC" to the client.

That said, I'm certain there are others that will be happy to pick up and
use your code. Thanks for posting it!

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oO2SbvMdt5gQnBon%2BisJgtRzDH4_k%3DxY1GSHXqyQafLwA%40mail.gmail.com.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to