Hi Aleks,

On Sat, Aug 11, 2018 at 10:27:42AM +0200, Aleksandar Lazic wrote:
> I think it is a requeue mechanism for the connection and not a selector for
> a server or a backend, but I can be wrong.

That's it. I'll try to explain shortly. You're probably aware how the
queuing mechanism works in haproxy when maxconn is set on a server :
once maxconn is reached, requests are queue either into the server's
queue, if something forces this request to use this specific server
(cookie, ...) otherwise into the backend's queue. Till now, our queues
were very fair (it was already shown on some blog posts from various
users over the last decade). A server would always consult both its
own queue and the backend's queue and pick the oldest request so that
the order of arrival was always preserved.

Now with this new feature, it is possible to change the dequeuing
order when a server picks a request from the queues. There are two
criteria for this :
  - the request's class
  - the position in the queue for a given class.

The server will always consult classes with lowest value first. And
within this class, it will pick the oldest waiting request. The
"set-priority-class" action allows you to set the class, and mark a
request as very important or unimportant. A good rule of thumb is to
consider that rare but important requests should be given a low class
number, that common requests should be given the default class number
(unchanged) and that expensive and painful requests which are not very
urgent should be given a high class number (dequeued only once no other
request competes with them). The "set-priority-offset" action allows to
tweak the apparent age of the request in the queue so that a server can
pick a request before another one for a given class. This is not used
to deal with the request's importance, but with the preferred response
time. For example, if your site periodically refreshes the pages but
cannot start to render before all objects are loaded, it could happen
that the browser clears the page when reloading the HTML part, then
takes ages to fetch css, js, etc, making the page unreadable for several
seconds every minute for a reader. By applying a time offset to these
extra components, you will make the mandatory elements such as CSS or JS
load much faster than the HTML one, resulting in an extra delay before
starting to fetch the HTML part (hence the page is not yet cleared), and
a shorter delay for the CSS/JS parts (making it render faster once cleared).
Similarly you could be a hosting provider willing to offer certain
guarantees on the page load time to certain customers. With this you
could easily say that those paying for premium service are guaranteed
to see a 100 ms faster load time than those paying the entry level one,
simply by applying a -100ms offset on their requests.

Some people want to use such features the other way around. Certain
sites have low importance stuff like an avatar upload button, a profile
settings page, etc, on which people "waste their time" instead of making
use of the main site, but still making use of the bandwidth and processing
power. Sometimes they simply want to say that such auxiliary requests are
applied an extra delay when there's competition to reach the servers. Just
by adding an extra 1 second offset to such requests, you'll slow them down
when the servers are highly loaded, and preserve the resources for the
other requests.

It's really impressive when you run two load generators in parallel. You
will typically see, say, 100 ms response time for both of them by default.
Then you apply +100ms to the requests coming from one of them, and then
you'll see a distribution like 66/166ms with the load of the slow one
dropping as its response time increases, giving more resources to the
other one, allowing its traffic to be processed faster.

I hope I helped clear your doubts.

I'm having a few comments below :

> listen|frontend test001
>   bind :8080
>   # some other options
>   http-request set-priority-class -10s if PAY_BUTTON

The class just uses integers, not delays. Also it's an interesting case
you have here, as many sites prefer to *increase* the delay on the pay
button or even once there's anything in your cart. There's a reason :
visitors who don't find what they're looking for are likely to quit the
site, so you need to improve their experience while they're searching.
Once their shopping cart is filled with a few articles, they're not
willing to spend as much time looking for them again on another site,
so they're very likely to accept to wait (even if that scares them).
Thus by delaying their traffic you can improve others' experience. Yes
I know it's dirty, but I don't operate a shopping site :-)

>   http-request set-priority-offset 5s if LOGO

That's a typically good example, yes, as nobody cares about the logo
being loaded fast.

>   # as a sample expression can also be this, right?
>   http-request set-priority-class \
>     %[req.fhdr(User-Agent),51d.single(DeviceType,IsMobile,IsTablet)]

No, it takes a constant expression. I'm not sure whether it would
really make sense to make it support sample expressions. I'm not
necessarily against it, it's just that I think it comes with extra
cost and complexity for very low value in the end. Very likely you
can do this using 2 or 3 rules only.

>   # could this work ?
>   use_backend high_priority if priority-class > 5

We don't have a sample fetch to retrieve the value, but it would be
trivial to implement as the value is present in the stream. Feel free
to take a look at how priority-class and priority-offset work for this.
Right now you can already achieve this by setting a variable anyway, but
I can see value in using the class to take a routing decision.


Reply via email to