Questioning the relevance of the write buffer
brenuart opened this issue · comments
As far as I know, a TCP output stream is already buffered "by nature". I mean the TCP stack itself has its own buffers (transmit window or else).
Adding another buffer on top of the stack increases the memory consumption (slightly) but also increase the amount of data lost when a connection is abruptly interrupted.
We set the buffer size to 0 since a while and did not notice any performance penalty.
I'm just wondering if that feature should stay and whether it has any positive benefit.
What do you think?
I'm hesitant to totally remove the ability to buffer the output stream mainly because I don't have profiling data for every environment. There could be certain environments where buffering provides a better experience. From just googling around, it seems there are a lot of opinions on buffering socket output streams, but no strong consensus.
On the other hand, I am open to changing the default to be unbuffered. But I'm also hesitant to do that since the buffer has existed since the TCP appender was created, and I don't have any concrete performance data for any environment.
I understand. For your information we are running the appender on MacOS, Windows, Linux and Docker with the buffer set to 0 without any issue.
I'm just concerned about the amount of data that may be lost when a connection is lost and the write buffer doesn't help...
One could also argue that flushing the TCP output stream is not required and is actually a noop since there is no way to actually force the TCP stack to send the data currently in its buffers.
Anyway, feel free to close this issue or add a note about it in the documentation ;-)