You can check to see whether the problem is a channel startup problem or a latency problem by calling channel->WaitForConnected(gpr_inf_future(GPR_CLOCK_MONOTONIC)) before you start sending RPCs on the channel. That call won't return until the channel has completed the DNS lookup and established a connection to the server, so if you start timing after that, your timing will exclude the channel startup time.
If you see that the channel startup time is high but the RPCs flow quickly once the startup time is passed, then the problem is either the DNS lookup or establishing a connection to the server. In that case, please try running with the environment variables GRPC_VERBOSITY=DEBUG GRPC_TRACE=client_channel_routing,pick_first and share the log, so that we can help you figure out which one is the problem. If you see that the channel startup time is not that high but that the RPCs are actually flowing more slowly over the network, then the problem might be network congestion of some sort. Also, if the problem does turn out to be channel startup time, note that it probably won't matter much in practice, as long as your application creates the channel once and reuses it for all of its RPCs. We do not recommend a pattern where you create a channel, send a bunch of RPCs, then destroy the channel, and then do that whole thing again later when you need to send more RPCs. I hope this information is helpful. On Sunday, August 8, 2021 at 9:34:43 AM UTC-7 sureshb...@gmail.com wrote: > *Environment* > > 1. Both client and server are C++ > 2. Server might be running either locally or in different system > 3. In case of remote server, it is in same network. > 4. Using SYNC C++ server > 5. Unary RPC > > Our performance numbers are very low for running 1000 RPC calls > (continuous calls through loop for testing) it takes about 10 seconds when > server running in different PC. > > The client creates channel using *hostname:portnumber *method and using > this approach the local server were also taking similar 10 seconds for 1000 > calls. Later we modified channel creation for local server by using > *localhost:port > *then it was much improved performance, all the 1000 calls completed > within 300 ms. > > Based on the above test, we strongly believe DNS resolution seems to cause > slow performance as change hostname to localhost results in huge > performance gain, however that is not possible for servers running on > different PC. > > Can someone help with this? Is DNS the real culprit or what else can be > changed to get good performance throughput in this case. > > Please let me know if there any other input required for this. > -- 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/94f2ae84-81c9-4fb0-bd63-dd3e6fc2a3a7n%40googlegroups.com.
