[squid-users] Individual delay pools and youtube

[dan at getbusi.com]

Thanks Amos




Sorry if that wasn’t clear, but yeah, 7 KB/s was the desired speed in that test. 




I was testing against an ISO in an S3 bucket of ours. I would start the download using http:// and get 7 KB/s (great). Then cancel it and edit the URL to https:// and get ~90 KB/s.




Oh, and I almost forgot: (I can’t remember whether this has been reported but) there’s also a problem with delay_parameters, such that our software has to x2 any restriction that’s configured when generating the squid config.




So, if I want to configure a 56 kbps restriction our software actually writes:


delay_parameters 1 -1/-1 14336/14336




In order to achieve the correct limit (7 KB/s). Not sure if that could be related to this at all.




P.S. We’re pretty fond of delay_pools and their simplicity—including the fact that it can all be handled by Squid without any lower-level networking concerns.

On Mon, Apr 20, 2015 at 1:25 AM, Amos Jeffries <squid3 at treenet.co.nz>
wrote:

> On 17/04/2015 1:30 p.m., djch wrote:
>> I just wanted to revive this thread to note that:
>> 
>> - Delay pools apply just fine to HTTPS requests in Squid 2.7.
>> - Delay pools in Squid 3.4.x are also applied to HTTPS but the speed is not
>> correct. 
>>   - If I apply a 56 Kbps limit the HTTP download tops out at ~7 KB/s.
> That *is* correct.
>    56K *bits* /sec == 7K *Bytes* /sec.
>    7x8 = 56
>> If I
>> download the same file from the same server via HTTPS it tops out at
>> ~90KB/s. If I download the same file over HTTPS with no delay pools
>> configured it tops at around 3MB/s.
> Are you sure thats actually HTTPS ?
> CONNECT tunnels these days could contain HTTP/2, SPDY, WebSockets or
> data in some other (compressed?) format. Any of which achieve faster
> percieved "download" than HTTP using the same basic bytes/sec data rate.
> NP: squid-2.7 contains a CONNECT bug that prevents SPDY HTTP/2 and
> Websockets working properly.
>> 
>> So I guess that would make this a bug? Which I assume nobody wants to fix
>> 'cause they're going to be deprecated at some point soon?
>> 
> Its a matter of interest. With FOSS you have to cause someone to be
> interested in fixing the bug. Best way to do that is to fix it yourself
> and present a patch and get it through review to merge. Second best is
> to find someone to pay to do all that. Or you can join the many people
> who opted just to wait and pray someone else will give it to them free
> one day.
> There is another option with delay pools. The pooling system is *just* a
> packet rate limiting system. The OS these days have several such QoS
> systems built in that work far better than Squid algorithms (admittedly
> not on a HTTP per-message basis). If you want total traffic control give
> those a try.
> Amos
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20150419/76799cca/attachment.html>