Re: connslots and the pending queue

On Thu, Jun 25, 2009 at 09:40:41AM -0700, Tod Sambar wrote:
> The connslots feature is terrific but there was/is one issue with our
> configuration.  Specifically, the pending queue for the servers in our
> backend queue always have a value of 0 (srv->nbpend), whereas, the
> pending queue for the backend proxy has an ever-accumulating value
> (px->nbpend).  The result of this is that the current connslots()
> calculation is always a value greater than or equal to the maxqueue
> values for each of the servers in the backend.

No, you can set "maxqueue" on the backend to fix a limit. And it is even suggested :-)

> I modified the haproxy server with the following change just prior to
> the return 1 on the last line of acl_fetch_connslots:
>
>    // Subtract all connections queued on the backend
>    test->i -= px->nbpend;
>
> Does this seem like a reasonable patch to submit or might I have a
> configuration issue that results in all pending connections
> accumulating at the backend level rather than at the server level?

For the reason above you don't need it :-) BTW, I have also added to my todo list the notion of using the number of backend connections in ACLs. This will make it easier to ignore the status of the queue. You'll just have to think how many connections max you want to process per backend, regardless of the number of available servers. The queue will get the excess for down servers. Alternatively we could also have another metric indicating how many avg connections per server a backend has. This will be the number of connections on a backend divided by the number of available servers, which will represent a real workload metric.

> I see that if the session is not established the pending connection is
> always accumulated at the backend rather than the server

The session is only set into the server's queue if it has a good reason to be there (cookie, hash, ...). Otherwise it is installed in the backend's queue so that the first available server can take it.

> -- since we
> disable keepalive for this particular application I would guess that's
> why there are no established sessions pending...

exactly.

Regards,
Willy Received on 2009/06/26 02:47