[squid-dev] [PREVIEW] Response delay pools
eduard.bagdasaryan at measurement-factory.com
Sat Dec 24 08:26:27 UTC 2016
This patch introduces a new "response_delay_pools" feature.
The feature restricts Squid-to-client bandwidth and applies to both
cache hits and misses.
When Squid starts delivering the final HTTP response to a client, Squid
checks response_delay_pool_access rules (supporting fast ACLs only), in
the order they were declared. The first rule with a matching ACL wins.
If (and only if) an "allow" rule won, Squid assigns the response to the
corresponding named delay pool.
If a response is assigned to a delay pool, the response becomes subject
to the configured bucket and aggregate bandwidth limits of that pool,
similar to the current "class 2" server-side delay pools, but with a
brand new, dedicated "individual" filled bucket assigned to the
The new feature serves the same purpose as the existing client-side
pools: both features limit Squid-to-client bandwidth. Their common
interface was placed into a new base BandwidthBucket class. The
difference is that client-side pools do not aggregate clients and always
use one bucket per client IP. It is possible that a response becomes a
subject of both these pools. In such situations only matched response
delay pool will be used for Squid-to-client speed limiting.
The accurate SMP support (with the aggregate bucket shared among
workers) is outside this patch scope. In SMP configurations,
Squid should automatically divide the aggregate_speed_limit and
max_aggregate_size values among the configured number of Squid
I have not synced with last v5 yet: this patch applies to v4 r14793.
To speed up the process and initiate the discussion I am posting with
"preview" flag and meanwhile start merging with the current v5 version.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 97548 bytes
Desc: not available
More information about the squid-dev