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_at_gmail.com> wrote:
> On Mon, Nov 25, 2013 at 11:26 AM, Michele Mase' <michele.mase_at_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
Received on Mon Nov 25 2013 - 14:02:08 MST
This archive was generated by hypermail 2.2.0 : Mon Nov 25 2013 - 12:00:05 MST