I am trying to devise a traffic shaping & prioritization scheme for
a reverse proxy setup on Linux (Debian etch).
What I ideally want to do is:
1. Restrict total traffic throughput to 5mbit.
2. Prioritize traffic within this ceiling by response content-type:
text/* - highest priority
image/* - middle priority
*/* - lowest priority
In other words, */* is allocated a small guaranteed minimal amount
of bandwidth (e.g. 1mbit), but may use up to 5mbit if it's not being
used by requests with a higher priority.
Multiple requests within each priority band should be dealt with
fairly.
The intention is to ensure that if our outgoing pipe is saturated,
page view requests will be serviced quickly. (An alternate strategy
is to prioritize based on content-length or even the number of bytes
sent to the client, but the above mime-types gives a reasonable
approximation of this.)
It's my understanding that squid's delay pools are not able to
borrow bandwidth from each other; they're only able to set a maximum
amount of bandwidth each class may use. This limits us to carving up
our 5mbit into pieces for each type of traffic, potentially limiting
bandwidth utilisation.
So my question is: does anyone know of a good way to achieve this
goal, with or without squid? We have a reasonably complex setup
(header & content rewriting, vary-by-cookie, etc.) and squid seems
to work quite well here (with the help of FilterProxy), but since we
have such a small uplink, traffic prioritisation is something of a
must-have.
Does anyone have real-world experience with this sort of traffic
shaping?
