On Thu, Nov 22, 2007, Amos Jeffries wrote:
> The code itself maybe. However the side-effects of using it should be
> checked and tested well.
> I believe the data is buffered by the kernel on receipt to a large degree
> these days, whether the client app reads it out or not. Throttling the
> inbound side of the transaction would cause these buffers to fill faster
> than emptied and an overflow can be expected at some point outside squid.
> Whether any specific OS handles that nicely or not is an ongoing
> networking problem.
> The catch-22 is that throttling in this manner in a client app does not
> actually save any bandwidth until the OS buffer is has reached overflow.
Well, the problem is that you've now got two buckets - the squid provided
one, and the send/receive buffers at either end of the TCP connection.
> My opinion is that the joint application of collapsed-forwarding and
> improved caching is the better approach to take when server-side bandwidth
> is a consideration.
It might be possible to check the local send/receive queue size when
calculating delay pool figures.. ah, thats too much work at the moment.
Adrian
-- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -Received on Wed Nov 21 2007 - 19:32:07 MST
This archive was generated by hypermail pre-2.1.9 : Sat Dec 01 2007 - 12:00:05 MST