The analysis was made using firebug from different browsers, using different proxyes/ direct access; with the "problematic" proxy, what I can see is an high "waiting" time, indicating that the header's page response is high. Therefore in cache.log i see many local=xxxxxx:yyyy remote=yyyyyy:zzzzzz FD xxxx flags=1: read/write failure: (110) Connection timed out local=xxxxxx:yyyy remote=yyyyyy:zzzzzz FD xxxx flags=1: read/write failure: (32) Broken pipe WARNING: Closing client connection due to lifetime timeout How could I test network related problems such as: Imix traffic limit Delay Bandwidth ....? Michele Masè On Mon, Nov 25, 2013 at 1:57 PM, Kinkie <gkinkie@xxxxxxxxx> wrote: > On Mon, Nov 25, 2013 at 11:26 AM, Michele Mase' <michele.mase@xxxxxxxxx> wrote: >> Problem: internet navigation is extremely slow. >> I've used squid from 1999 with no problems at all; during last month, >> one proxy gave me a lot of troubles. >> First we upgraded the system, from RHEL5.x - squid 2.6.x to RHEL6.x >> squid3.4.x with no improvements. >> Second, we have bypassed the Trend Micro Interscan proxy (the parent >> proxy) without success. >> Third: I do not know what to do. >> So what should be done? >> Some configuration improvements (sysctl/squid)? >> Could it be a network related problem? (bandwidth/delay/MTU/other)? > > Hi Michele, > "extremely slow" is quite a poor indication, unfortunately. Can you > measure it? e.g. by using apachebench (ab) or squidclient to measure > the time download a large file and a small file through the proxy from > a local source and from a remote source. Then repeating the same from > the box where Squid runs and then from a different box. > > Think about what has remained unchanged since when there was no > performance problems: e.g. network cables, switches, routers etc. > > Kinkie
