On 17/06/2015 10:11 p.m., Horváth Szabolcs wrote: > Hello! > > We're having serious problems with a squid proxy server. > > The good news is the problem can be reproduced at any time in our production squid system. > > Environment: > - CentOS release 6.5 (Final) with Linux kernel 2.6.32-431.29.2.el6.x86_64 > - squid-3.1.10-22.el6_5.x86_64 (a bit old, CentOS ships this version) > > Problem description: > - if we have a few mbytes/sec https traffic AND > - delay_classes are in place AND > - delay pools are full (I mean the available bandwidth for the customer are used) > > -> then squid is trickling https traffic down to the clients in 65-70 byte packets. > > Our WAN routers are not designed to handle thousands of 65-70 byte packets per seconds and therefore we have some network stability issues. > > I tracked down the following: > - if delay_pools are commented out (clients can go with full speed as they like) -> the problem eliminates, https traffic flows with ~1500 byte packets > - if we use only http traffic, there is no problem: http traffic flows with ~1500 byte packets even if the delay pools are full > > Our test URL is www.opengroup.org/infosrv/DCE/dce122.tar.gz, which is available both on http and https protocol. > > Resources can be found at http://support.iqsys.hu/logs/ > > 1. squid.conf -> squid configuration file > 2. http-delaypool.pcap: > - wget -c http://www.opengroup.org/infosrv/DCE/dce122.tar.gz, > - delay pools are active > - http flows with 1500 byte packets > 3. http-nodelaypool.pcap: > - wget -c http://www.opengroup.org/infosrv/DCE/dce122.tar.gz, > - delay pools are INACTIVE > - http flows with 1500 byte packets > 4. https-delaypool.pcap: > - wget -c https://www.opengroup.org/infosrv/DCE/dce122.tar.gz, > - delay pools are active > - http flows with 69 byte packets -> this is extremely bad > 5. https-nodelaypool.pcap: > - wget -c https://www.opengroup.org/infosrv/DCE/dce122.tar.gz, > - delay pools are INACTIVE > - http flows with 1500 byte packets > > My question is: is it a known bug? Sounds like http://bugs.squid-cache.org/show_bug.cgi?id=2907, which was fixed in Squid-3.5.3. see comment #16 in the bug report for a 3.1 workaround patch. Though if your production server has high performance requirements the sleep(1) workaround is not the best. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
