Re: [grpc-io] Best practice for client channel

2017-09-05 Thread 'Eric Anderson' via grpc.io
On Tue, Sep 5, 2017 at 6:32 AM, Amit Saha 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

Re: [grpc-io] Best practice for client channel

2017-09-05 Thread 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 >>

Re: [grpc-io] Best practice for client channel

2016-09-19 Thread 'Ran Bi' via grpc.io
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 wrote: > Reading another thread

Re: [grpc-io] Best practice for client channel

2016-09-16 Thread 'Eric Anderson' via grpc.io
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

Re: [grpc-io] Best practice for client channel

2016-09-16 Thread 'Eric Anderson' via grpc.io
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