Hello James,
On Wed, Mar 23, 2011 at 05:03:31PM -0400, James Bardin wrote:
> Hello,
>
> I've been going through haproxy in depth recently, but I can't quite
> figure out the details with full, min, and maxconn.
Aie, I hate to explain that, it's complex, I explain it badly and after that, people generally are even more confused. Let's try again...
> First of all, fullconn confuses me, and this example doesn't help
>
> > Example :
> > # The servers will accept between 100 and 1000 concurrent connections each
> > # and the maximum of 1000 will be reached when the backend reaches 10000
> > # connections.
> > backend dynamic
> > fullconn 10000
> > server srv1 dyn1:80 minconn 100 maxconn 1000
> > server srv2 dyn2:80 minconn 100 maxconn 1000
>
> What's the point of the "fullconn 10000" here? Won't the servers
> already be maxed out at 2000 connections, and already at their
> respective maximums long before 10000 connections are made?
First, fullconn is only useful if both minconn and maxconn are configured on the server lines.
When you only configure maxconn on a server, the server has a static connection limit defined by this maxconn. Usually what is observed is that a server has very good performance up to a small number of concurrent requests, has smoothly decaying performance up to a higher threshold and performs very badly past this threshold (due to swapping or thread limit being hit).
When your server always shows short response times, you can run on low maxconn values, it'll be fast. If your server relies on a slow database or local I/O, or external content providers, you might want to use higher connection values in order to ensure that no requests remains in the queue when the server still has some idle CPU that could be used.
For some sites with huge variations in traffic patterns (eg: newspapers, games, etc...) there is no one-size-fits-all for maxconn. The sites might be serving information extremely fast under low loads, implying that a low maxconn would be perfect, but suddenly experience major slowdowns under extreme loads due to some external events. In this case, running too low a maxconn is a waste of processing power because the servers will spend their time waiting for I/Os and won't use all their potential to serve contents.
For such sites, we designed the dynamic connection regulation mechanism, which involves minconn and fullconn.
minconn is in fact the maxconn to use under low loads. Fullconn defines at what number of concurrent connections on the whole backend, we should use the configured maxconn. And the progression between those two numbers is linear.
So in your example above, under low loads your servers will run with a 100 connections limit (minconn). This limit will linearly increase, to reach maxconn (1000) when the number of connections on the whole backend reaches fullconn (10000). Above 10000, it remains at maxconn. That means that if there are 5000 connections on your backend, your servers will be running with a limit half-way between minconn and maxconn (550).
So while the parameter names are not perfect, keep in mind that :
In general, I suggest you don't use that, otherwise you'll have in turn to explain it to your coworkers :-)
> Maxconn can be declared in defaults, frontend, listen, under server,
> and global as well. Does the first limit hit take priority; e.g. if I
> set "maxconn 10" in global, are my *total* connections for everything
> limited to 10? Should I set:
> (global maxconn) >= sum(frontend maxconns) >= sum(server maxconns)
The global maxconn applies to the process, which means to the sum of the frontend connections. The default/frontend/listen maxconn applies frontend per frontend. The servers' maxconns are per server. If you configure higher maxconns on your servers than what the frontend can bring, it's not a problem, it just means you'll never use the queue.
Please tell me if I confused you.
Willy Received on 2011/03/24 23:24
This archive was generated by hypermail 2.2.0 : 2011/03/24 23:30 CET