# Requests queued despite not reaching maxconn

**URL:** https://discourse.haproxy.org/t/requests-queued-despite-not-reaching-maxconn/11304
**Category:** Help!
**Created:** [October 22, 2024, 9:48am UTC](https://discourse.haproxy.org/t/requests-queued-despite-not-reaching-maxconn/11304 "2024-10-22T09:48:14Z")
**Posts on this page:** 16
**Page:** 1

<div class="post-metadata">

### Author: ![nco33](https://avatars.discourse-cdn.com/v4/letter/n/a3d4f5/32.png) [@nco33](https://discourse.haproxy.org/u/nco33)
#### Post date: [October 22, 2024, 9:48am UTC](https://discourse.haproxy.org/t/requests-queued-despite-not-reaching-maxconn/11304/1 "2024-10-22T09:48:14Z")

</div>

In the HAProxy stats page, it displays on some of my backends a Queue Time of ~2s. I don’t understand why some requests are being queued despite `maxconn` being set to 60000 (it never reached that value).  
Here is my conf:

```auto
global
  daemon
  chroot /var/lib/haproxy
  user haproxy
  group haproxy
  maxconn 60000
  stats socket /var/lib/haproxy/stats

defaults
  mode http
  log global
  option dontlognull
  option forwardfor except 127.0.0.0/8
  option redispatch
  retries 3
  timeout http-request 5s
  timeout connect 2s
  timeout client 5s
  timeout server 5s
  timeout http-keep-alive 1800s
  timeout check 5s

frontend main
  bind 127.0.0.1:83
  use_backend %[req.hdr(host),lower,word(1,.)]
  stats uri /api/v1/haproxy-stats

resolvers resolv-conf
  parse-resolv-conf
  accepted_payload_size 8192
  timeout resolve 20s

backend someBackend
  http-reuse always
  http-request set-header Host someBackend.net
  balance roundrobin
  server-template aka_ 9 someBackend.net:80 check resolvers resolv-conf resolve-prefer ipv4

```

What am I missing ? Also, strangely, in the stats page, the session limit is set to 1 on all of my backends:

 ![Capture d’écran 2024-10-22 à 11.47.14](https://us1.discourse-cdn.com/flex016/uploads/haproxy/original/2X/a/a201b53d743ca020b94962ff045cd283d09e1487.png)

---

<div class="post-metadata">

### Author: ![adarragon](https://avatars.discourse-cdn.com/v4/letter/a/7bcc69/32.png) [@adarragon](https://discourse.haproxy.org/u/adarragon)
#### Post date: [November 4, 2024, 10:29am UTC](https://discourse.haproxy.org/t/requests-queued-despite-not-reaching-maxconn/11304/2 "2024-11-04T10:29:22Z")

</div>

> Also, strangely, in the stats page, the session limit is set to 1 on all of my backends:

It is expected because maxconn is only relevant for servers and proxies with frontend capabilities.

For backend, this value (on the stats page) reflects the `fullconn` tunable instead.

Now as for why you sometime see a non-zero Queue time while you didn’t reached the maxconn value: Queue time doesn’t necessarily mean that the connection spent time in frontend or server queue, it is corresponds to the time between the connection was accepted and some input data is being processed. Due to IO activity, this could sometime show some delay. Value should be close to 0 though most of the time, except if the system/network is heavily loaded.

---

<div class="post-metadata">

### Author: ![nco33](https://avatars.discourse-cdn.com/v4/letter/n/a3d4f5/32.png) [@nco33](https://discourse.haproxy.org/u/nco33)
#### Post date: [November 4, 2024, 10:49am UTC](https://discourse.haproxy.org/t/requests-queued-despite-not-reaching-maxconn/11304/3 "2024-11-04T10:49:43Z")

</div>

> [@adarragon](#):
>
> It is expected because maxconn is only relevant for servers and proxies with frontend capabilities.

I don’t understand. My backends do have a frontend (nginx) with dynamic use\_backend names.  
In that case, does that mean there will be only one active session at the time and other requests will be queued ?

> [@adarragon](#):
>
> Now as for why you sometime see a non-zero Queue time while you didn’t reached the maxconn value: Queue time doesn’t necessarily mean that the connection spent time in frontend or server queue, it is corresponds to the time between the connection was accepted and some input data is being processed. Due to IO activity, this could sometime show some delay. Value should be close to 0 though most of the time, except if the system/network is heavily loaded.

System/network is not overloaded at all. What I find strange is that the queue time is always about 2s, like my timeout connect. Are they related somehow ?

---

<div class="post-metadata">

### Author: ![adarragon](https://avatars.discourse-cdn.com/v4/letter/a/7bcc69/32.png) [@adarragon](https://discourse.haproxy.org/u/adarragon)
#### Post date: [November 4, 2024, 1:54pm UTC](https://discourse.haproxy.org/t/requests-queued-despite-not-reaching-maxconn/11304/4 "2024-11-04T13:54:28Z")

</div>

> [@nco33](#):
>
> I don’t understand. My backends do have a frontend (nginx) with dynamic use\_backend names.  
> In that case, does that mean there will be only one active session at the time and other requests will be queued ?

No, it means `maxconn` value will only be displayed for frontends as “limit” on the stats page. For backends this “limit” reflects the [fullconn](https://docs.haproxy.org/dev/configuration.html#fullconn) value which is a backend specific tunable.

> System/network is not overloaded at all. What I find strange is that the queue time is always about 2s, like my timeout connect. Are they related somehow ?

Oh I missed that part, 2 seconds? Not even ms? In that case it is strange indeed because 2s is huge given that you don’t hit maxconn at all. Is it the case for all servers a just specific one?

---

<div class="post-metadata">

### Author: ![nco33](https://avatars.discourse-cdn.com/v4/letter/n/a3d4f5/32.png) [@nco33](https://discourse.haproxy.org/u/nco33)
#### Post date: [November 4, 2024, 3:01pm UTC](https://discourse.haproxy.org/t/requests-queued-despite-not-reaching-maxconn/11304/5 "2024-11-04T15:01:05Z")

</div>

> [@adarragon](#):
>
> No, it means `maxconn` value will only be displayed for frontends as “limit” on the stats page. For backends this “limit” reflects the [fullconn](https://docs.haproxy.org/dev/configuration.html#fullconn) value which is a backend specific tunable.

So, it means that, like in my screenshot, fullconn is set to only 1 ? So there will be only 1 maximum request processed at a given time ?

> [@adarragon](#):
>
> Oh I missed that part, 2 seconds? Not even ms? In that case it is strange indeed because 2s is huge given that you don’t hit maxconn at all. Is it the case for all servers a just specific one?

2000ms yes. Sometimes 2001ms, always a little bit higher than 2000ms. I wonder why.  
It’s impacts all of my servers but since the value “Queue time max” in the stats page is only for the last 1024 requests, it doesn’t appear everywhere everytime.

---

<div class="post-metadata">

### Author: ![adarragon](https://avatars.discourse-cdn.com/v4/letter/a/7bcc69/32.png) [@adarragon](https://discourse.haproxy.org/u/adarragon)
#### Post date: [November 4, 2024, 3:20pm UTC](https://discourse.haproxy.org/t/requests-queued-despite-not-reaching-maxconn/11304/6 "2024-11-04T15:20:01Z")

</div>

> [@nco33](#):
>
> So, it means that, like in my screenshot, fullconn is set to only 1 ? So there will be only 1 maximum request processed at a given time ?

No, fullconn set to 1 doesn’t mean that 1 maximum request will be processed. In your case I think you can ignore it, as it is relevant when minconn != maxconn, please read the doc for fullconn carefully, it is well explained

> 2000ms yes. Sometimes 2001ms, always a little bit higher than 2000ms. I wonder why.  
> It’s impacts all of my servers but since the value “Queue time max” in the stats page is only for the last 1024 requests, it doesn’t appear everywhere everytime.

I don’t understand yet either. Which haproxy version are you using? Could you share a bit more of your config, namely frontend/backend sections? It could help to understand what’s going on

---

<div class="post-metadata">

### Author: ![nco33](https://avatars.discourse-cdn.com/v4/letter/n/a3d4f5/32.png) [@nco33](https://discourse.haproxy.org/u/nco33)
#### Post date: [November 4, 2024, 3:34pm UTC](https://discourse.haproxy.org/t/requests-queued-despite-not-reaching-maxconn/11304/7 "2024-11-04T15:34:48Z")

</div>

> [@adarragon](#):
>
> No, fullconn set to 1 doesn’t mean that 1 maximum request will be processed. In your case I think you can ignore it, as it is relevant when minconn != maxconn, please read the doc for fullconn carefully, it is well explained

Ok, thanks.

> [@adarragon](#):
>
> I don’t understand yet either. Which haproxy version are you using? Could you share a bit more of your config, namely frontend/backend sections? It could help to understand what’s going on

I use HAProxy v2.2.31.  
Regarding my config, I already put it in my first post. The only difference is that I have about 30 backends (You can see in my frontend that I use\_backend dynamically based on the host header). They are all parameterized the same, like this:

```auto
backend <someHost>
  http-reuse always
  http-request set-header Host <someHost>.net
  balance roundrobin
  server-template aka_ 9 <someHost>.net:80 check resolvers resolv-conf resolve-prefer ipv4

```

---

<div class="post-metadata">

### Author: ![nco33](https://avatars.discourse-cdn.com/v4/letter/n/a3d4f5/32.png) [@nco33](https://discourse.haproxy.org/u/nco33)
#### Post date: [November 4, 2024, 4:46pm UTC](https://discourse.haproxy.org/t/requests-queued-despite-not-reaching-maxconn/11304/8 "2024-11-04T16:46:03Z")

</div>

I just tried to set:

```auto
timeout connect 1792ms

```

An explicitly odd value to see if it’s related to Queue time and indeed it is !  
Now in my stat page I sometime see Queue times roughly equals to 1792ms:

 ![Capture d’écran 2024-11-04 à 17.42.28](https://us1.discourse-cdn.com/flex016/uploads/haproxy/original/2X/a/a2bf1d4081d1b7c393806ec64328c09dfceae6e2.png)  
Does that mean that request waiting to connect to the server are put in the queue ?

---

<div class="post-metadata">

### Author: ![nco33](https://avatars.discourse-cdn.com/v4/letter/n/a3d4f5/32.png) [@nco33](https://discourse.haproxy.org/u/nco33)
#### Post date: [November 5, 2024, 9:05am UTC](https://discourse.haproxy.org/t/requests-queued-despite-not-reaching-maxconn/11304/9 "2024-11-05T09:05:52Z")

</div>

timeout queue default value is the value of timeout connect, that’s why. Still, I don’t know why items are put in the queue

---

<div class="post-metadata">

### Author: ![adarragon](https://avatars.discourse-cdn.com/v4/letter/a/7bcc69/32.png) [@adarragon](https://discourse.haproxy.org/u/adarragon)
#### Post date: [November 5, 2024, 9:56am UTC](https://discourse.haproxy.org/t/requests-queued-despite-not-reaching-maxconn/11304/10 "2024-11-05T09:56:49Z")

</div>

Ok thanks for additional info

Even if it doesn’t help with this issue, please consider upgrading to a newer LTS because 2.2 is EOL. If that’s not feasible at least update to the last 2.2.33 to benefit from last known bugfixes.

Now back to your issue, I think I was able to reproduce… It when the request is redispatched (due to “option redispatch”), redispatch time is counted under “Queue time” it seems. The maximum value I can see is roughly `retries` x `timeout connect` on my end. I assume it is a side-effect but not a bug in itself.

---

<div class="post-metadata">

### Author: ![adarragon](https://avatars.discourse-cdn.com/v4/letter/a/7bcc69/32.png) [@adarragon](https://discourse.haproxy.org/u/adarragon)
#### Post date: [November 5, 2024, 10:03am UTC](https://discourse.haproxy.org/t/requests-queued-despite-not-reaching-maxconn/11304/11 "2024-11-05T10:03:01Z")

</div>

If requests are often redispatched, it may indicate that some servers are having trouble to handle the load, or that the network path between haproxy and some servers is not stable

---

<div class="post-metadata">

### Author: ![nco33](https://avatars.discourse-cdn.com/v4/letter/n/a3d4f5/32.png) [@nco33](https://discourse.haproxy.org/u/nco33)
#### Post date: [November 5, 2024, 10:48am UTC](https://discourse.haproxy.org/t/requests-queued-despite-not-reaching-maxconn/11304/12 "2024-11-05T10:48:38Z")

</div>

> [@adarragon](#):
>
> Now back to your issue, I think I was able to reproduce… It when the request is redispatched (due to “option redispatch”), redispatch time is counted under “Queue time” it seems. The maximum value I can see is roughly `retries` x `timeout connect` on my end. I assume it is a side-effect but not a bug in itself.

Even if redispatch enabled, request should be put in the queue only if there aren’t any server available, which is not my case.

---

<div class="post-metadata">

### Author: ![adarragon](https://avatars.discourse-cdn.com/v4/letter/a/7bcc69/32.png) [@adarragon](https://discourse.haproxy.org/u/adarragon)
#### Post date: [November 5, 2024, 11:38am UTC](https://discourse.haproxy.org/t/requests-queued-despite-not-reaching-maxconn/11304/13 "2024-11-05T11:38:49Z")

</div>

They are not in the queue, the “Queue time” metric may be misleading but you are wrongly assuming thay they are put in the queue because the “Queue time” metric doesn’t show 0

As explained before, even when maxconn isn’t reached, Queue time may be != 0 if redispatched occurs, in which case queue time accounts for retry/redispatch time, not actual queue time (since the request wasn’t queued).

Try disabling redispatch and see if the metric still shows inconsistent results, or try solving the issue on servers side to prevent redispatch from occuring (they occur in case of failed connection attempts to the servers)

---

<div class="post-metadata">

### Author: ![nco33](https://avatars.discourse-cdn.com/v4/letter/n/a3d4f5/32.png) [@nco33](https://discourse.haproxy.org/u/nco33)
#### Post date: [November 5, 2024, 1:13pm UTC](https://discourse.haproxy.org/t/requests-queued-despite-not-reaching-maxconn/11304/14 "2024-11-05T13:13:48Z")

</div>

I still don’t get why the “Queue time” metric shows 2s, that’s a lot ! is there a delay between retries ?  
You’re right, it might be related to redispatch. I have 9 servers per backend and I see on the stat page that the server which had the redispatch is not the same as the one who had 2s queue time:

 ![Capture d’écran 2024-11-05 à 14.06.56](https://us1.discourse-cdn.com/flex016/uploads/haproxy/original/2X/7/7719473b2c00db3d555c75a8ea14297cae6a1de1.png)

---

<div class="post-metadata">

### Author: ![adarragon](https://avatars.discourse-cdn.com/v4/letter/a/7bcc69/32.png) [@adarragon](https://discourse.haproxy.org/u/adarragon)
#### Post date: [November 5, 2024, 2:29pm UTC](https://discourse.haproxy.org/t/requests-queued-despite-not-reaching-maxconn/11304/15 "2024-11-05T14:29:20Z")

</div>

Yes there is MIN(timeout connect, 1s) delay applied between 2 retry attempts, this is documented here: [HAProxy version 3.1-dev11-1 - Configuration Manual](https://docs.haproxy.org/dev/configuration.html#4.2-retries)

This is to avoid immediate reconnect to server thay may be restarting

---

<div class="post-metadata">

### Author: ![nco33](https://avatars.discourse-cdn.com/v4/letter/n/a3d4f5/32.png) [@nco33](https://discourse.haproxy.org/u/nco33)
#### Post date: [November 6, 2024, 2:46pm UTC](https://discourse.haproxy.org/t/requests-queued-despite-not-reaching-maxconn/11304/16 "2024-11-06T14:46:18Z")

</div>

Thank you for all of your answers