Hi Amos,
On Wed, Jan 18, 2012 at 04:43:12PM +0100, Andreas Schulz wrote:
> On Thu, Jan 12, 2012 at 12:53:18PM +1300, Amos Jeffries wrote:
> Hi,
>
> > So doing I/O to a disk log somehow speeds up TCP throughput? strange
> definitely right ... but I'm not sure if this speeds up TCP throughput -
> but speeds up Squid ;-)
>
> > This sounds a bit like the speed problems we see with very low traffic
> > rates. When the I/O loops get very few requests through they end up
> > pausing in 10ms time chunks each processing cycle to prevent CPU overload
> > doing lots of processing on very small amounts of bytes.
> hmm, speed problems should be no problem. I tested also the following:
>
> - iptables -t nat -A PREROUTING -p tcp --dport 8081 -j DNAT --to-destination 212.112.181.17:80
> - iptables -t nat -A POSTROUTING -p tcp -d 212.112.181.17 -j MASQUERADE
>
> no changes in client so every browser url gets redirected to the ment.
> website. Dirty but what I found out was same speed as a direct internet
> connection. So speed problems not given - btw: our internet access has
> speed of 1G :-)
>
> > This release is getting a bit old now and has a few I/O buffering bugs in
> > it that may be related.
> > Please try the 3.1.18 Debian package from Wheezy / testing repositories
> > (may require some dependency updates as well).
> installed testing release - no success :-(
>
> > 145 connect() calls in 0.05 ms, all failing? does not seem right at
> > all.
> you're right, all calls where connect for IPv6-addresses. But we have
> this failed calls also with other sites. Testing deactivated IPv6 in OS
> was decided based on these connect-calls. Anyway the connect calls still
> used IPv6-addresses. But we have these connect fails with other websites
> too. So I don't think it's not the root cause.
>
> > Given the time measure I don't think its related, but probably worth
> > knowing and fixing. Did the section 5 trace show what was going on here?
> hmm I didn't find anything helpful but there are lots of messages. I can
> provide complete log if needed ...
>
> > Add here:
> > refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
> configured
>
> > Eeek! nearly unlimited access to the whole Internet. Why?
> only for test purposes :-) Therefore I used tcp/8081, our customer uses
> 8080 and this config has some ACLs more ... I stripped down
> configuration to exclude configuration problems ...
>
> Another really interesting result from another test. In my home
> environment I have also a Squid vom Debian Squeeze. Running in a VZ but
> on 32 Bit environment with nearly same configuration - no problem! And
> only with a 12MBit internet access ...
>
> So should this be a 64bit-related problem? I can't believe ...
I checked also current Squeeze environment in my home office and I had
no performance problems :-) So this a proof that is related only to our
company environment. We also find out that starting strace on squid
process speeds up in the same way as debugging squid.
After sev. other tests (using wheezy as os platform, different kernels
from debian backport) we find out - using Linux Kernel 3.1 from backport
in addition with backportet firmware drivers for bnx2 supported network
cards solves the problem - with squid 3.1.6 :-)
Many thanks for yr advises ...
regards, Andreas
Received on Tue Jan 24 2012 - 16:33:10 MST
This archive was generated by hypermail 2.2.0 : Tue Jan 24 2012 - 12:00:04 MST