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 <squ...@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@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
