On Wed, 16 Mar 2011 10:38:50 -0400 (EDT), rpereyra_at_lavabit.com wrote:
>>
>> I have a transparent bridge proxy squid 3.x on a debian 6 box. It
>> performs
>> extremely well for browsing, but it turns out very slow when
>> downloading
>> sibgle files.
>>
>> wget
>>
>> http://mirrors.adams.net/centos/5.5/isos/i386/CentOS-5.5-i386-bin-1of7.iso
>> --10:47:33--
>>
>> http://mirrors.adams.net/centos/5.5/isos/i386/CentOS-5.5-i386-bin-1of7.iso
>> => `CentOS-5.5-i386-bin-1of7.iso.4'
>> Resolviendo mirrors.adams.net... 216.138.0.215
>> Connecting to mirrors.adams.net|216.138.0.215|:80... conectado.
>> Petici�n HTTP enviada, esperando respuesta... 200 OK
>> Longitud: 653.910.016 (624M) [application/octet-stream]
>>
>> 3% [==>
>> ] 25.028.303 33.29K/s ETA 8:45:17
>>
>>
>> but when I don't use squid the speed looks grown up 500K/s.
>>
>> Any hint ? Squid for browsing are working very well.
>>
>> Thanks for any help.
>>
>> roberto
>
>
> I found this issue in the mailist:
>
> http://www.mail-archive.com/squid-users@squid-cache.org/msg72970.html
>
> This bug was solved ?
>
> roberto
I believe we got the last of the reply processing leak-like things in
3.1.11. The default Debian 6.0 bundled package does not have these
fixes. Grab the package from the "wheezy"/"sid" repositories.
Slow speed on large files can also be traced to 1KB read cycles on the
reply body. When combined with a 10ms IO stand-off on the FD and async
event overheads that can become quite slow when there are no or few
other requests going through.
There fact that squid does not grow that 1KB to larger chunks is a
know speed problem. I have an experimental patch coming up for that if
you are happy to help test.
Amos
Received on Thu Mar 17 2011 - 02:15:15 MDT
This archive was generated by hypermail 2.2.0 : Thu Mar 17 2011 - 12:00:03 MDT