Best practice for client channel

[ran...@addepar.com]

Hi

I want to know what is the best practice to use GRPC client channels.

For each GRPC client-server pair, should I just create a single channel that is shared among all threads, or should I create a pool of channels and make sure one channel is used by one thread at a time?

I am asking this is because I used to run into mysterious issues that some channel got stuck in the middle of some long stream RPC and the client thread blocks forever, while the same issue never happens to "channel pool" model.

Best

[Eric Anderson]

You should share a single channel across threads. Only in very heavy throughput (when we start talking about trying to fully saturate a server NIC) should you even begin to consider do something else.

I can't say what bug you experienced before, but only doing one RPC on each channel at a time is simpler and is less likely to encounter bugs and interop issues. But if/when you encounter something like that, please bring it to our attention so that it can be addressed.

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/14013c59-dc14-48d7-8521-8915c32820a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eric Anderson]

Reading another thread made me want to tweak my statement:

Only in very heavy throughput (when we start talking about trying to fully saturate a server NIC) should you even begin to consider do something else.

Even in that case you probably shouldn't use multiple Channels. Instead, you would want a load balancer that might make multiple connections to the backend. Use different channels when you are contacting different backends. That is the only form of "channel pool" you might want: to look up a single shared Channel per backend.

[Ran Bi]

Thanks for your reply, Eric!

The bug I observed only happened in production environment, and I haven't figured out a way to repro it locally. I will definitely let you know if there is any updates.

On Fri, Sep 16, 2016 at 9:25 PM Eric Anderson <ej...@google.com> wrote:

Reading another thread made me want to tweak my statement:

Only in very heavy throughput (when we start talking about trying to fully saturate a server NIC) should you even begin to consider do something else.

Even in that case you probably shouldn't use multiple Channels. Instead, you would want a load balancer that might make multiple connections to the backend. Use different channels when you are contacting different backends. That is the only form of "channel pool" you might want: to look up a single shared Channel per backend.

On Fri, Sep 16, 2016 at 8:49 PM, Eric Anderson <ej...@google.com> wrote:

You should share a single channel across threads. Only in very heavy throughput (when we start talking about trying to fully saturate a server NIC) should you even begin to consider do something else.

I can't say what bug you experienced before, but only doing one RPC on each channel at a time is simpler and is less likely to encounter bugs and interop issues. But if/when you encounter something like that, please bring it to our attention so that it can be addressed.

On Thu, Sep 15, 2016 at 5:01 PM, ran.bi via grpc.io <grp...@googlegroups.com> wrote:

Hi

I want to know what is the best practice to use GRPC client channels.

For each GRPC client-server pair, should I just create a single channel that is shared among all threads, or should I create a pool of channels and make sure one channel is used by one thread at a time?

I am asking this is because I used to run into mysterious issues that some channel got stuck in the middle of some long stream RPC and the client thread blocks forever, while the same issue never happens to "channel pool" model.

Best

--
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+u...@googlegroups.com.

[Amit Saha]

On Saturday, September 17, 2016 at 2:25:54 PM UTC+10, Eric Anderson wrote:

Reading another thread made me want to tweak my statement:

Only in very heavy throughput (when we start talking about trying to fully saturate a server NIC) should you even begin to consider do something else.

Even in that case you probably shouldn't use multiple Channels. Instead, you would want a load balancer that might make multiple connections to the backend. Use different channels when you are contacting different backends. That is the only form of "channel pool" you might want: to look up a single shared Channel per backend.

Digging up this thread. I guess you are suggesting, that a "client" program (which may be composed of multiple worker threads/processes) should only have a single channel for each gRPC backend it wants to talk to. This channel remains "open" during the lifetime of the client. This backend is of course being connected to via a LB/proxy.

Does my understanding seem correct?

Thank you.

Best Wishes,

Amit.

 

On Fri, Sep 16, 2016 at 8:49 PM, Eric Anderson <ej...@google.com> wrote:

You should share a single channel across threads. Only in very heavy throughput (when we start talking about trying to fully saturate a server NIC) should you even begin to consider do something else.

I can't say what bug you experienced before, but only doing one RPC on each channel at a time is simpler and is less likely to encounter bugs and interop issues. But if/when you encounter something like that, please bring it to our attention so that it can be addressed.

On Thu, Sep 15, 2016 at 5:01 PM, ran.bi via grpc.io <grp...@googlegroups.com> wrote:

Hi

I want to know what is the best practice to use GRPC client channels.

For each GRPC client-server pair, should I just create a single channel that is shared among all threads, or should I create a pool of channels and make sure one channel is used by one thread at a time?

I am asking this is because I used to run into mysterious issues that some channel got stuck in the middle of some long stream RPC and the client thread blocks forever, while the same issue never happens to "channel pool" model.

Best

--
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+u...@googlegroups.com.

[Eric Anderson]

On Tue, Sep 5, 2017 at 6:32 AM, Amit Saha <amits...@gmail.com> wrote:

Digging up this thread.

This thread was just shy of a year old. It would have been better to start another thread and just reference this one with a link.

I guess you are suggesting, that a "client" program (which may be composed of multiple worker threads/processes) should only have a single channel for each gRPC backend it wants to talk to. This channel remains "open" during the lifetime of the client.

Yeah, although saying a channel is "open" (I assume vs closed/shutdown) isn't saying much. A Channel may be "operational" without having any active connections (it'll just create one on demand).

Also, I understand that in some applications it can be hard to 1) know whether you'll told to a particular backend again and 2) coordinate sharing a Channel. It's okay to use multiple Channels. But if you can use a single Channel, try to do.

This backend is of course being connected to via a LB/proxy.

In the earlier conversation it would have been via client-side load balancing logic. gRPC provides an API for replacing the client-side load balancer. I was suggesting "inside" the channel via that API is the best place for this sort of logic instead of "outside" via creating multiple Channels. But it's also pretty tangential; few users should have to worry about it.