Re: minconn, maxconn and fullconn (again, sigh!)
Lukas Tribus wrote: [dd] > > > It would be nice however to understand minconn/fullconn too. If a > > backend has several servers with identical minconn, maxconn and weight, > > what's the point of having minconn? The load will be always distributed > > evenly between all the servers notwithstanding minconn/fullconn, > > correct? > > If the load is REALLY the same, sure. That's just never the case in > real life for a number of reasons: > > - different load-balancing algorithms > - different client behavior > - session persistence > - long-running TCP connections (websocket, et all) Oh, that was the missing link to understand the thing. > > But yes, like I already mentioned, minconn/fullconn is addressing a > very specific requirement that I don't think comes up very often. Thank you Lukas, you have been very helpful. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: minconn, maxconn and fullconn (again, sigh!)
On Thu, 11 Feb 2021 at 05:31, Victor Sudakov wrote: > > Lukas Tribus wrote: > > > > On Wed, 10 Feb 2021 at 16:55, Victor Sudakov wrote: > > > > > > I can even phrase my question in simpler terms. What happens if the sum > > > total of all servers' maxconns in a backend is less than the maxconn > > > value in the frontend pointing to the said backend? > > > > Queueing for "timeout queue" amount of time, and then return 503 error > > And what happens in TCP mode, after the "timeout queue" amount of time? > I suppose the TCP connection with the client is reset? Yes, that's the only choice. > > > > > See: > > > > timeout queue > > https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#4.2-timeout%20queue > > > > maxconn > > https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#5.2-maxconn > > > > > > I really suggest you ignore minconn and fullconn, and focus on maxconn > > instead. The latter is a must-have (and must-understand). Really > > maxconn (global, frontend and per server ) is the single most > > important performance knob in haproxy. > > Maxconn is rather clear, especially when one is sure about two things: > > 1. A server's maxconn value is always a hard limit (notwithstanding if > there is a minconn configured for the server). Yes. > 2. Connections outnumbering the sum total of a backend's servers > maxconns are queued for the "timeout queue" amount of time and then > dropped. If, for any reason, we can't use another server with free slots, yes. > It would be nice however to understand minconn/fullconn too. If a > backend has several servers with identical minconn, maxconn and weight, > what's the point of having minconn? The load will be always distributed > evenly between all the servers notwithstanding minconn/fullconn, > correct? If the load is REALLY the same, sure. That's just never the case in real life for a number of reasons: - different load-balancing algorithms - different client behavior - session persistence - long-running TCP connections (websocket, et all) But yes, like I already mentioned, minconn/fullconn is addressing a very specific requirement that I don't think comes up very often. Lukas
Re: minconn, maxconn and fullconn (again, sigh!)
Lukas Tribus wrote: > > On Wed, 10 Feb 2021 at 16:55, Victor Sudakov wrote: > > > > I can even phrase my question in simpler terms. What happens if the sum > > total of all servers' maxconns in a backend is less than the maxconn > > value in the frontend pointing to the said backend? > > Queueing for "timeout queue" amount of time, and then return 503 error And what happens in TCP mode, after the "timeout queue" amount of time? I suppose the TCP connection with the client is reset? > > See: > > timeout queue > https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#4.2-timeout%20queue > > maxconn > https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#5.2-maxconn > > > I really suggest you ignore minconn and fullconn, and focus on maxconn > instead. The latter is a must-have (and must-understand). Really > maxconn (global, frontend and per server ) is the single most > important performance knob in haproxy. Maxconn is rather clear, especially when one is sure about two things: 1. A server's maxconn value is always a hard limit (notwithstanding if there is a minconn configured for the server). 2. Connections outnumbering the sum total of a backend's servers maxconns are queued for the "timeout queue" amount of time and then dropped. Are the above statements correct? It would be nice however to understand minconn/fullconn too. If a backend has several servers with identical minconn, maxconn and weight, what's the point of having minconn? The load will be always distributed evenly between all the servers notwithstanding minconn/fullconn, correct? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: minconn, maxconn and fullconn (again, sigh!)
Hello Victor, On Wed, 10 Feb 2021 at 16:55, Victor Sudakov wrote: > > I can even phrase my question in simpler terms. What happens if the sum > total of all servers' maxconns in a backend is less than the maxconn > value in the frontend pointing to the said backend? Queueing for "timeout queue" amount of time, and then return 503 error (and this really is desirable as opposed to hitting maxconn on a frontend or even worse, global maxconn, because a few milliseconds of delay do not hurt and returning a proper HTTP error in distress is way better then some obscure connection timeout). See: timeout queue https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#4.2-timeout%20queue maxconn https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#5.2-maxconn I really suggest you ignore minconn and fullconn, and focus on maxconn instead. The latter is a must-have (and must-understand). Really maxconn (global, frontend and per server ) is the single most important performance knob in haproxy. Lukas
Re: minconn, maxconn and fullconn (again, sigh!)
I can even phrase my question in simpler terms. What happens if the sum total of all servers' maxconns in a backend is less than the maxconn value in the frontend pointing to the said backend? Victor Sudakov wrote: > Dear Colleagues, > > The dynamic limit is probably one of the darker sides of Haproxy > configuration. One of the best explanations I've found is > https://www.mail-archive.com/haproxy@formilux.org/msg04782.html > but still I'm missing some points. > > Consider the following configuration: > > > frontend bar > maxconn 1 > default_backend foo > > backend foo > server server1 server1: minconn 10 maxconn 100 weight 100 > server server2 server2: minconn 10 maxconn 100 weight 100 > > > This configuration will set the automatic implicit fullconn=1000 to the > backend "foo", correct? > > "maxconn 100" is still a hard limit, correct? > > So, when there happen to be 500 connections to the backend "foo", 200 > of them will be served by server1 and server2, what will happen to the > other 300 connections? > > The same can be asked about the example from the Haproxy documentation > with the explicit fullconn: > > > backend dynamic > fullconn 1 > server srv1 dyn1:80 minconn 100 maxconn 1000 > server srv2 dyn2:80 minconn 100 maxconn 1000 > > > "maxconn 1000" is still a hard limit, correct? > > When 4000 connections come to this backend, srv1 and srv2 will serve 2000 > of them (each reaching its hard limit at "maxconn=1000"), what will happen > to the other 2000 ? > > -- > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > 2:5005/49@fidonet http://vas.tomsk.ru/ > -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
minconn, maxconn and fullconn (again, sigh!)
Dear Colleagues, The dynamic limit is probably one of the darker sides of Haproxy configuration. One of the best explanations I've found is https://www.mail-archive.com/haproxy@formilux.org/msg04782.html but still I'm missing some points. Consider the following configuration: frontend bar maxconn 1 default_backend foo backend foo server server1 server1: minconn 10 maxconn 100 weight 100 server server2 server2: minconn 10 maxconn 100 weight 100 This configuration will set the automatic implicit fullconn=1000 to the backend "foo", correct? "maxconn 100" is still a hard limit, correct? So, when there happen to be 500 connections to the backend "foo", 200 of them will be served by server1 and server2, what will happen to the other 300 connections? The same can be asked about the example from the Haproxy documentation with the explicit fullconn: backend dynamic fullconn 1 server srv1 dyn1:80 minconn 100 maxconn 1000 server srv2 dyn2:80 minconn 100 maxconn 1000 "maxconn 1000" is still a hard limit, correct? When 4000 connections come to this backend, srv1 and srv2 will serve 2000 of them (each reaching its hard limit at "maxconn=1000"), what will happen to the other 2000 ? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
