Could you provide some stats on your observation and how you are measuring this? Two streams sharing a connection vs. separate connections could be faster due to these reasons: - One less socket to service: less system calls, context switching, cache misses etc. - Better batching of data from different streams on a single connection resulting in better connection utilization and larger av. pkt size on the wire.
On Friday, August 17, 2018 at 3:30:17 PM UTC-7, eleano...@gmail.com wrote: > > Hi Carl, > > Thanks for the very detailed explanation! my question is why I observed > using a separate TCP connection per stream was SLOWER! > > If the single TCP connection for multiple streams are faster (Regardless > the reason), will the connection get saturated? e.g. too many streams > sending on the same TCP connection. > > > On Friday, August 17, 2018 at 3:25:54 PM UTC-7, Carl Mastrangelo wrote: >> >> 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/a72ee911-067a-4dd0-a6ee-c8ad6ca03677%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
