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 -
