1 TCP connection for all streams (really RPCs) should be faster.
On Monday, August 20, 2018 at 1:15:14 PM UTC-7, eleano...@gmail.com wrote:
>
> Hi Carl,
>
> It is hard to show my code as I have a wrapper API on top of grpc.
>
> However, are you suggesting that using 1 tcp connection per stream
Hi Carl,
It is hard to show my code as I have a wrapper API on top of grpc.
However, are you suggesting that using 1 tcp connection per stream should
be faster than using 1 tcp connection for all streams?
On Monday, August 20, 2018 at 11:14:43 AM UTC-7, Carl Mastrangelo wrote:
>
> Can you sho
Can you show your code? This may just be a threading problem.
On Saturday, August 18, 2018 at 9:02:59 PM UTC-7, eleano...@gmail.com wrote:
>
> Hi Srini,
>
> The way how I do it:
> for single connection:
> 1. send 1 request via request StreamObserver, to let initial connection
> established
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 Polavarap
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 1 requests
3. end the timer when see all results from the response
StreamObserver.onNext() that the client passed to the serve
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 di
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
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 fr
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
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,
10 matches
Mail list logo