• Choose a category
• All
• Classic-Fiction

The mapping between Squid clients and actual buckets is a bit complicated. Squid uses three different constructs to do it: access rules, delay pool classes, and types of buckets. First, Squid checks a client request against the delay_access list. If the request is a match, it points to a particular delay pool. Each delay pool has a class: 1, 2, or 3. The classes determine which types of buckets are in use. Squid has three types of buckets: aggregate, individual, and network:

A class 1 pool has a single aggregate bucket.

A class 2 pool has an aggregate bucket and 256 individual buckets.

A class 3 pool has an aggregate bucket, 256 network buckets, and 65,536 individual buckets.

As you can probably guess, the individual and network buckets correspond to IP address octets. In a class 2 pool, the individual bucket is determined by the last octet of the client's IPv4 address. In a class 3 pool, the network bucket is determined by the third octet, and the individual bucket by the third and fourth octets.

For the class 2 and 3 delay pools, you can disable buckets you don't want to use. For example, you can define a class 2 pool with only individual buckets by disabling the aggregate bucket.

When a request goes through a pool with more than one bucket type, it takes bandwidth from all buckets. For example, consider a class 3 pool with aggregate, network, and individual buckets. If the individual bucket has 20 KB, the network bucket 30 KB, but the aggregate bucket only 2 KB, the client receives only a 2-KB allotment. Even though some buckets have plenty of traffic, the client is limited by the bucket with the smallest amount.

Configuring Squid

Before you can use delay pools, you must enable the feature when compiling. Use the —enable-delay-pools option when running ./configure. You can then use the following directives to set up the delay pools.

delay_pools

The delay_pools directive tells Squid how many pools you want to define. It should go before any other delay pool-configuration directives in squid.conf. For example, if you want to have five delay pools:

delay_pools 5

The next two directives actually define each pool's class and other characteristics.

delay_class

You must use this directive to define the class for each pool. For example, if the first pool is class 3:

delay_class 1 3

Similarly, if the fourth pool is class 2:

delay_class 4 2

In theory, you should have one delay_class line for each pool. However, if you skip or omit a particular pool, Squid doesn't complain.

delay_parameters

Finally, this is where you define the interesting delay pool parameters. For each pool, you must tell Squid the fill rate and maximum size for each type of bucket. The syntax is:

delay_parameters N

rate/size [rate/size [rate/size]]

The rate value is given in bytes per second, and size in total bytes. If you think of rate in terms of bits per second, you must remember to divide by 8.

Note that if you divide the size by the rate, you'll know how long it takes (number of seconds) the bucket to go from empty to full when there are no clients using it.

A class 1 pool has just one bucket and might look like this:

delay_class 2 1

delay_parameters 2 2000/8000

For a class 2 pool, the first bucket is the aggregate, and the second is the group of individual buckets. For example:

delay_class 4 2

delay_parameters 4 7000/15000 3000/4000

Similarly, for a class 3 pool, the aggregate bucket is first, the network buckets are second, and the individual buckets are third:

delay_class 1 3

delay_parameters 1 7000/15000 3000/4000 1000/2000

delay_initial_bucket_level

This directive sets the initial level for all buckets when Squid first starts or is reconfigured. It also applies to individual and network buckets, which aren't created until first referenced. The value is a percentage. For example:

delay_initial_bucket_level 75%

In this case, each newly created bucket is initially filled to 75% of its maximum size.

delay_access

This list of access