feat(transport): Enable TCP_NODELAY. #120
Conversation
The combination of the Nagle algorithm on a client, and delayed ack on a server can introduce up to 200ms latency if a small gRPC messages is sent with multiple writes. Enable TCP_NODELAY to make sure that neither client, nor server buffer their messages for too long when exchaning small requests.
|
@dominiquelefevre I think this is a good idea to add but I'd like to look into what other grpc libraries do as defaults. I am curious if grpc-go's http2 impl sets nodelay by default, same with netty? |
|
grpc-go sets nodelay by default, and I do not know of any way to disable that. |
|
@dominiquelefevre ok that makes sense, I am happy to merge this but maybe in a follow up PR we should probably provide this as a config option as well. |
|
@LucioFranco, I am opposed to a config option. TCP_NODELAY is required for services that exchange small requests. If requests are big, sending one more incomplete TCP packet with a http request prologue introduces no noticeable overhead, thus it makes no sense to disable TCP_NODELAY in such scenarios. So, just keep the API minimal. |
|
@dominiquelefevre no I agree, what I mean't was to enable it by default and let users disable it. Not a high priority and we don't have to do anything until someone needs it. Thanks for all the help! :) |
The combination of the Nagle algorithm on a client, and delayed ack on a server can introduce up to 200ms latency if a small gRPC messages is sent with multiple writes. Enable TCP_NODELAY to make sure that neither client, nor server buffer their messages for too long when exchaning small requests.
The combination of the Nagle algorithm on a client, and delayed ack on a server
can introduce up to 200ms latency if a small gRPC messages is sent with multiple
writes.
Enable TCP_NODELAY to make sure that neither client, nor server buffer their
messages for too long when exchaning small requests.