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/3c0ead44-88bd-490c-9fba-43063f6b8041%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
