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@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
