What's "tcp-backlog" in redis.conf

Question

I'm confused by tcp-backlog in redis.conf:

# TCP listen() backlog.
#
# In high requests-per-second environments you need an high backlog in order
# to avoid slow clients connections issues. Note that the Linux kernel
# will silently truncate it to the value of /proc/sys/net/core/somaxconn so
# make sure to raise both the value of somaxconn and tcp_max_syn_backlog
# in order to get the desired effect.
tcp-backlog 511

Is tcp-backlog the size of "complete connection queue" (three-way handshake complete, what is described here) or "incomplete connection queue"?

If it means "complete connection queue" then why should I raise tcp_max_syn_backlog which limits the size of an incomplete connection queue?

Answer 1

Is tcp-backlog the size of "complete connection queue" (three-way handshake complete, what is described here) or "incomplete connection queue"?

tcp-backlog is the size of complete connection queue. In fact, Redis passes this configuration as the second parameter of the listen(int s, int backlog) call.

@GuangshengZuo already had a good answer for this question. So I'll focus on the other one.

If it means "complete connection queue" then why should I raise tcp_max_syn_backlog which limits the size of an incomplete connection queue?

Quote from the doc you mentioned:

The implementation uses two queues, a SYN queue (or incomplete connection queue) and an accept queue (or complete connection queue). Connections in state SYN RECEIVED are added to the SYN queue and later moved to the accept queue when their state changes to ESTABLISHED, i.e. when the ACK packet in the 3-way handshake is received. As the name implies, the accept call is then implemented simply to consume connections from the accept queue. In this case, the backlog argument of the listen syscall determines the size of the accept queue.

We can see that items in complete connection queue are moved from the incomplete connection queue.

If you have a large somaxconn with a small tcp_max_syn_backlog, then you might NOT have enough items to be moved to the complete connection queue, and the complete connection queue might never be full. Many requests might have already been dropped from the first queue before they have the chance to be moved to the second.

So only raise the value of somaxconn might NOT work. You have to raise both of them.