Reading Squid Delay Pool Rates and Burst Capacity
Read a Squid delay pool as a refill rate and burst allowance, then choose a separate control when the requirement concerns concurrent client connections.
delay_pools 1
delay_class 1 1
delay_parameters 1 64000/128000Read the pair as restore/maximum: this class 1 pool receives 64,000 bytes of allowance per second and holds at most 128,000 bytes. The refill is 512,000 bits per second before network overhead. Available allowance permits a burst; the larger maximum does not double the sustained rate.
The fragment illustrates parameters on Squid versions providing delay pools. A deployment still needs delay_access to select traffic and its ordinary access controls.
| Requirement | Relevant quantity |
|---|---|
| Sustained pacing | Refill, in bytes per second |
| Burst allowance | Bucket capacity, in bytes |
| Monthly or daily quota | Consumption accumulated over the period, with its reset policy |
| Simultaneous connections | A connection-count condition such as maxconn |
A 64,000-byte maximum would not stop a download after 64,000 bytes: allowance keeps refilling. It is not cumulative usage accounting. Traffic assigned to one class 1 pool also shares its aggregate allowance rather than receiving that rate per person.
maxconn measures established TCP connections associated with a directly connected client's IP, not bytes or users. An intermediary or NAT can combine several people under that source. Keep the requirement in its own units before choosing a directive.