Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Willy Tarreau <w <at> 1wt.eu>
Subject: Re: minconn, maxconn and fullconn
Newsgroups: gmane.comp.web.haproxy
Date: Thursday 24th March 2011 22:24:09 UTC (over 6 years ago)
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 :
  - minconn defines the limit when load is low
  - maxconn defines the limit when load is high
  - fullconn defines what a high load is

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
 
CD: 3ms