The single connection time for the whole process is about 2.75 sec, and the multiple connection time is about 3.5 sec. I run this test multiple times, and the single connection is always a bit faster than the multiple connections
On Saturday, August 18, 2018 at 8:37:22 PM UTC-7, Srini Polavarapu wrote: > > 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/3a2bd3a8-01f9-4115-976f-fa4637bfee06%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
