-
From our TCP benchmarks, values over 128 don't seem to have any measurable benefits, even with hundreds of thousands of connections. On the contrary, during very high TCP and CPU load, smaller backlog seems to dramatically improve latency for clients that keep idle TCP connections. During normal/low load, smaller backlog doesn't seem to have any benefits. When measured against "aggressive" clients that immediately close the TCP connection once their query is answered, backlog smaller than 128 was measured to hurt performance. The application's backlog size is ultimately limited by net.core.somaxconn, which has been set to 128 prior to Linux 5.4. Therefore, this change only affects newer kernels and those who have manually set this value to a higher size. For more, see https://gitlab.labs.nic.cz/knot/knot-resolver/-/merge_requests/968
From our TCP benchmarks, values over 128 don't seem to have any measurable benefits, even with hundreds of thousands of connections. On the contrary, during very high TCP and CPU load, smaller backlog seems to dramatically improve latency for clients that keep idle TCP connections. During normal/low load, smaller backlog doesn't seem to have any benefits. When measured against "aggressive" clients that immediately close the TCP connection once their query is answered, backlog smaller than 128 was measured to hurt performance. The application's backlog size is ultimately limited by net.core.somaxconn, which has been set to 128 prior to Linux 5.4. Therefore, this change only affects newer kernels and those who have manually set this value to a higher size. For more, see https://gitlab.labs.nic.cz/knot/knot-resolver/-/merge_requests/968
