[squid-dev] [PREVIEW] Response delay pools
Amos Jeffries
squid3 at treenet.co.nz
Mon Jan 9 06:33:10 UTC 2017
On 24/12/2016 9:26 p.m., Eduard Bagdasaryan wrote:
> Hello,
>
> 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
> matched response.
>
> 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
> workers.
>
> 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.
>
Thanks. Sorry I didn't get a chance to look at it yet. That should now
happen in the next few days.
Can you please add to the above an explanation of why this is being
added instead of improving ways to send TOS/NFMARK to feed the system
QoS bandwidth controls. We really should not be re-inventing QoS in
Squid (for about the third time AFAICT).
Amos
More information about the squid-dev
mailing list