Re: [squid-users] delay pools status

From: Beto Moreno <pamrtj_at_gmail.com>
Date: Sat, 22 Mar 2014 10:35:15 -0700

  Now that we are here learning, what is the latest bandwidth
management tool squid have for the sysadmins?
  Delays pools like u mention are the old stuff.

  I want to get most from my squid.

Thanks again Amos.

On Fri, Mar 21, 2014 at 7:38 PM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> On 22/03/2014 4:31 a.m., Beto Moreno wrote:
>> Hi, thanks Amos for always share your knowledge.
>>
>> "No there is 500KB/sec allocated to client response (download) traffic on
>> "first-come basis.
>>
>> "This is effectively the same configuration as kernel routing QoS
>> "controls allowing the Squid process to access 500KB/s of traffic inbound
>> "for servers and unlimited upload traffic to servers.
>>
>> Here squid decide what we can share to each connection, the first
>> machine get full bucket, if other machine arrive squid decide what he
>> can receive from the bucket and continue the same to others users?
>> Until they eat all the bucket and fill again the bucket to share?
>
> There is two things here:
> 1) the delay pool bucket size
> 2) the I/O buffer free space
>
> 500KB is larger than the maximum buffer size. The delay pool bucket gets
> more data only once every second.
>
> So what happens is with only one machine, the client buffer gets to fill
> its buffer several times over several reads until 500KB pool bucket is
> empty.
> The next second there are two machines, and each gets to fill its buffer
> in turn until the delay pool bucket is empty.
>
> Problem: So long as the delay pool is larger than the client buffer size
> there will be some (unbalanced) sharing of the buffer. If the client
> buffer is smaller than the delay pool you may see unpredictable
> situations where one client gets all the traffic for a few seconds then
> switches to another. With many clients some may get all the bandwidth
> and others none at all.
> This pool type relies heavily on clients having traditional browser
> behaviour. Whee a page was donloaded once then some time later another
> page, etc. With big gaps of no traffic by each client.
>
>>
>> example 2:
>>
>> delay_pool_count 1
>> delay_class 1 3
>> delay_parameters 1 500000/562500 -1/-1 4000/4000
>> delay_initial_bucket_level 100
>>
>> Start will full bucket, here we have one bucket of 500kb/s burst
>> 562kb/s for all my clients but each on my clients will get <=
>> 32kb/s(max 32kb/s) from their single bucket?
>
> Remembering the sequence of sharing above. With this class-3 pool type
> each client is only allowed to read up to 4000 bytes from the shared
> pool when it fills its buffer. With a maximum of 4000 bytes total each
> second if it tries to read a few bytes several times.
> The total traffic by all clients gets to 500000 Bytes in one second
> then reads are stopped until the global pool bucket refills. ie if 125
> clients all read their 4000 bytes each in one second the 126th client is
> not permitted to read.
>
> This mostly resolves the balancing problem described above. Relating to
> QoS this pool is effectively the same as QoS controls on the
> client->Squid connections controlling how much traffic got delivered to
> each client by Squid (downloads by client).
> But still pools is slightly worse than proper QoS as it does not cover
> requests/uploads, TCP packet overheads, and large response headers can
> cause buckets to go negative.
>
>>
>> About the QoS, is what I'm trying to manage, but I had been testing
>> squid delay-pools and they help in some manner controlling users
>> appetite.
>
> Yes. Any type of control helps in some manner. Squid delay pools are
> just old technology with some strange limits (like not covering uploads
> or TCP overheads). They do not work as well as newer QoS technology
> which had more knowledge and experience behind the design.
>
>>
>> QoS trying to see how to integrate with squid, because once squid
>> start controlling inbound is came of difficult to me because 80/443
>> are only seen by single client(squid), QoS won't see my lan
>> connections to those ports which are who eat my bandwidth, but working
>> on.
>
> qos_flows directive in squid.conf can tag traffic by type so you can
> control HIT/MISS with different rules if you want on the client<->squid
> connections.
>
> tcp_outgoing_tos / tcp_outgoing_mark directives tag traffic on the
> squid<->server connections according to ACL matches.
>
> As I understand it you setup QoS rules based on MARK or TOS to do the
> bandwidth allocation you would be doing with delay pools class and
> parameters directives. Then you setup squid.conf to tag the traffic into
> the QoS pool types the same as you would have done with delay_pool_access.
>
> Amos
Received on Sat Mar 22 2014 - 17:35:22 MDT

This archive was generated by hypermail 2.2.0 : Sun Mar 23 2014 - 12:00:05 MDT