I may have misinterpretted your question; are you asking why gRPC prefers to use a single connection, or why you observed using a separate TCP connection per stream was faster?
If the first, the reason is that the number of TCP connections may be limitted. For example, making gRPC requests from the browser may limit how many connections can exist. Also, a Proxy between the client and server may limit the number of connections. Connection setup and teardown is slower due to the TCP 3-way handshake, so gRPC (really HTTP/2) prefers to reuse a connection. If the second, then I am not sure. If you are benchmarking with Java, I strongly recommend using the JMH benchmarking framework. It's difficult to setup, but it provides the most accurate, believe benchmark results. On Friday, August 17, 2018 at 2:09:20 PM UTC-7, eleano...@gmail.com wrote: > > Hi Carl, > > Thanks for the explanation, however, that still does not explain why using > single tcp for multiple streamObserver is faster than using 1 tcp per > stream. > > On Friday, August 17, 2018 at 12:45:32 PM UTC-7, Carl Mastrangelo wrote: >> >> gRPC does connection management for you. If you don't have any active >> RPCs, it will not actively create connections for you. >> >> You can force gRPC to create a connection eaglerly by calling >> ManagedChannel.getState(true), which requests the channel enter the ready >> state. >> >> Do note that in Java, class loading is done lazily, so you may be >> measuring connection time plus classload time if you only measure on the >> first connection. >> >> On Friday, August 17, 2018 at 9:17:16 AM UTC-7, eleano...@gmail.com >> wrote: >>> >>> Hi, >>> >>> I am doing some experiment with gRPC java to determine the right gRPC >>> call type to use. >>> >>> here is my finding: >>> >>> creating 4 sets of StreamObservers (1 for Client to send request, 1 for >>> Server to send response), sending on the same channel is slightly after >>> than sending on 1 channel per stream. >>> I have already elimiated the time of creating initial tcp connection by >>> making a initial call to let the connection to be established, then start >>> the timer. >>> >>> I just wonder why this is the case? >>> >>> Thanks! >>> >>> -- 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 post to this group, send email to grpc-io@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/9f82deaa-1295-45af-93b4-fcd11a8bf0c0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
