# Haproxy settings priority

**URL:** <https://discourse.haproxy.org/t/haproxy-settings-priority/2237>\
**Category:** Help!\
**Created:** [March 14, 2018, 1:15pm UTC](https://discourse.haproxy.org/t/haproxy-settings-priority/2237 "2018-03-14T13:15:06Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![shivharsh](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.haproxy.org/shivharsh/32/388_2.png) [@shivharsh](https://discourse.haproxy.org/u/shivharsh)\
**Post date:** [March 15, 2018, 8:20am UTC](https://discourse.haproxy.org/t/haproxy-settings-priority/2237/2 "2018-03-15T08:20:37Z")

</div>

Hi,

In order to answer your questions, we first need to understand where and how maxconn property works.

Basically, maxconn property can be set in 3 different locations in HAProxy configuration (/etc/haproxy.cfg) file :  
1. maxconn in global section  
2. maxconn in listen section  
3. server maxconn

Now, coming to the **how** part:

1. **maxconn in global section** sets the maximum number of concurrent connections allowed per process (_by default HAProxy runs with a single process. Multiple processes can be triggered by configuring nbproc property_). Once this limit is reached, HAProxy stops accepting new connections and these requests are queued in socket queue in the kernel, waiting for the connections to become available.

2. **maxconn in listen section** sets the maximum number of concurrent connections allowed per listener. The default value for this maxconn is smaller than the global maxconn. In general, the listener maxconn comes into picture when there are multiple services handled by an haproxy instance. In such cases, the listener maxconn has to be configured in such a manner that a single service does not consume all the connections (defined by global maxconn) and the other service therefore stops working.

3. **server maxconn** sets the maximum number of concurrent connections allowed on a server. If this limit is reached, then the fate of the request depends on persistence. If the request has a cookie associated with it, it is then pooled in server queue to wait for an available connection on the server. If the request does not have a cookie associated, in that case it is forwarded to a server with lesser number of connections. Please note, the request stays in the queue for a period specified by **timeout queue** property. If the request stays in the queue longer than the timeout queue specified, then the request is dropped and a 503 page is returned to the user.

Now, to answer your first question:

> [@AleksASB](#):
>
> Please help me understand such “what if” scenario:
> 
> Client’s IP address is in stick table and he wants to establish another session from the same IP address but his “working” server (e.g. app-01) is full (number of connections = 1300) - this session will:
> 
> Drop  
> Hang  
> HAProxy put it to another server (e.g. app-02 or app-03) which number of current connections is lower?

Considering the ambiguity in the question, i have tried answering it based on below assumptions:  
**CASE 1:**

> **Assumption:**  
> global maxconn =1300  
> server app-01, maxconn=1300  
> server app-02, maxconn=1300
> 
> **Scenario:**  
> If the number of connections on server app-01 reach 1300 and a user makes a new request but from the same IP specified in stick table.

HAProxy would stop accepting new connections and the request would be queued in socket queue in the kernel.

**CASE 2:**

> Assumption:  
> global maxconn = 4000  
> server app-01, maxconn=1300  
> server app-02, maxconn=1300
> 
> **Scenario:**  
> If the number of connections on server app-01 reach 1300 and a user makes a new request but from the same IP specified in stick table.

The request would be accepted by HAProxy but would be queued in the server queue for a period specified by the the queue timeout property.

Coming to your second question,

> [@AleksASB](#):
>
> And the second question:
> 
> is this config:

No, both the configurations are not the same.

In the first configuration,

> [@AleksASB](#):
>
> backend app-servers  
> mode tcp  
> balance roundrobin  
> stick-table type ip size 900k expire 30m  
> stick on src  
> option tcp-check  
> maxconn 1300  
> server app-01 172.1.2.3:443 check port 443  
> server app-02 172.1.2.4:443 check port 443  
> server app-03 172.1.2.5:443 check port 443  
> server app-04 172.1.2.6:443 check port 443

the global maxconn is set to 1300 and there is no maxconn limit set for the backend servers. Therefore, in this case HAProxy will accept a maximum of 1300 concurrent connections, post which the new request would be queued in socket queue in kernel to wait for available connections.

Whereas in second configuration,

> [@AleksASB](#):
>
> backend app-servers  
> mode tcp  
> balance roundrobin  
> stick-table type ip size 900k expire 30m  
> stick on src  
> option tcp-check  
> server app-01 172.1.2.3:443 check port 443 maxconn 1300  
> server app-02 172.1.2.4:443 check port 443 maxconn 1300  
> server app-03 172.1.2.5:443 check port 443 maxconn 1300  
> server app-04 172.1.2.6:443 check port 443 maxconn 1300

there is no value set for global maxconn property, which will therefore default to the value set in DEFAULT\_MAXCONN at build time. The per server maxconn limit is however set at 1300 and if this limit is reached on a server, then request is either forwarded to a server with lesser number of connections or pooled in server queue for the server to become available depending on persistence.

Hope this is helpful !

---

_[View the full topic](https://discourse.haproxy.org/t/haproxy-settings-priority/2237)._