Re: request prioritization

From: Willy Tarreau <w#1wt.eu>
Date: Tue, 15 Dec 2009 23:30:51 +0100

Hello,

On Tue, Dec 15, 2009 at 10:04:10PM +0100, Jaroslav Gresula wrote:
> Hello,
>
> I use a haproxy queue in front of a server which serves two classes of
> requests. The two classes - let's call them A and B - can be matched
> using ACLs.
>
> My question is whether it is possible to instruct haproxy to dequeue
> class A requests with higher priority than class B requests?

you can't exactly do that right now (some minor changes are needed in the queuing/dequeuing method and will possibly be performed soon after some real-life tests).

However you can assign your requests some resources by sending them to a different backend with different numbers of concurrent connections.

For instance, consider you are selling CDs online. You want the users without anything in their basket to experience fast response times and the ones with at least on CD in their basket to have slower ones, because you know that once they have found what they need, they won't go away. You set your application to assign a cookie "BASKET" to the client once he has something in its basket.

You can then proceed that way :

frontend www

	acl has_basket hdr_sub(cookie) -i BASKET=
	use_backend slow if has_basket
	default_backend fast

backend fast
	server www1 1.1.1.1:80 maxconn 90

backend slow
	server www1 1.1.1.1:80 maxconn 10

See ? When the clients passing through backend "fast" will share 90 possible connections to the server, the ones through backend "slow" will only share 10 connections.

So this is not a priority per-se, but it's still a QoS setting. This is also sometimes used to reduce the rendering time caused

by large static objects : you send requests for .jpg and .swf
to the slow backend and the rest to the fast one. That way, the
page displays the fastest possible (.html, .js, .css, .png) and

the large objects can take more time but if properly declared in the HTML, don't prevent the page from displaying.

Hoping it matches your needs,
Willy Received on 2009/12/15 23:30