Hi Srini, The way how I do it: for single connection: 1. send 1 request via request StreamObserver, to let initial connection established 2. start the timer, send 10000 requests 3. end the timer when see all results from the response StreamObserver.onNext() that the client passed to the server. the logic is just System.out.println
for multiple connections: 1. send 1 request for each channel created, to let initial connection established 2 start the timer, send 1000 per connection, total 10 connections, so total 10000 requests 3. end the timer when see all the results from the response StreamObserver.onNext() that the client passed to the server, for all connections, the logic is just System.out.println Thanks! for multiple connection: 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/2c1a3739-6cc2-48d8-a75b-cc067995f55c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
