Hm... "Connection timed out" is an OS/TCPIP issue. Can you try using accessing the same resource from the server itself (e.g. with wget, GET or running firefox on the proxy server). It seems that there's something on the network level: faulty ethernet, switch, router, firewall or network line, or high packet loss somewhere on the path to the affected server(s).
On Mon, Nov 25, 2013 at 3:01 PM, Michele Mase' <michele.m...@gmail.com> wrote: > 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 <gkin...@gmail.com> wrote: >> On Mon, Nov 25, 2013 at 11:26 AM, Michele Mase' <michele.m...@gmail.com> >> 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 -- /kinkie