Re: [squid-users] finding the bottleneck

2012/2/17 Eliezer Croitoru <eliezer_at_ec.hadorhabaac.com>:
> hey there Eli(i think i know you)
Hi (maybe),
> any ssl interception will make the connection slower but it can be tricky.
> gmail is one big example of a site that has problems while working on plain
> http and on https will work better also will solve many problems because
> most ISP's wont do ssl interception.
Our ISP does, and not only do they do it, they also have buggy systems
that randomly do the intercepts even on websites that we told them
explicitly to whitelist...
(And before anyone says "just switch ISP" that is not my call).
> it also depends on your ISP interception machines.
> if they have a lot of users and less powerfull machines it will cause
> slowdowns!
Yeah, we don't know what they have exactly, we hope it's good stuff
the problem is that when we don't know how much slowdown our systems
are introducing it is harder to complain to the ISP because they can
just put the blame by us even if that is not the case....
I guess I could stick wireshark on the WAN port connecting to the ISP,
the client making the request and possibly the proxies on the way make
sure their times are all in exact sync and see what the time
difference between a request being made internally, it going out,
coming back etc. is but that is very involved....

> if you want to make sure it's not from your side connect a server in you
> infrastructure and use apache tools to test the connection to load on the
> server just to understand the differences of squid.
You mean just see what happens when I browse to a local machine
through the proxies... hmm, why didn't I think of that?
We do have a bunch of rules in place to optimize access to local
resources, but I guess if I undo them for test locations I could get
some level of a picture.
> also you can try to use iptables rules to bypass squid for tests.
That would not be possible for the locations with the problems... it
would be possible for more general testing though....
> that way you can clearly see if your infrastructure is the cause for the
> slowdowns.
Our network layout is more complicated, but maybe I can actually ask a
station in a problematic location to be moved to the ISP vlan and then
see how it behaves....
Thanks,
Eli
>
> Regards
> Eliezer
>
>
>
> On 17/02/2012 01:11, E.S. Rosenberg wrote:
>>
>> 2012/2/16 Luis Daniel Lucio Quiroz<luis.daniel.lucio_at_gmail.com>:
>>>
>>> Comments, behind...
>>>
>>> Le 12 janvier 2012 06:53, E.S. Rosenberg<esr_at_g.jct.ac.il>  a écrit :
>>>>
>>>> 2012/1/11 jeffrey j donovan<donovan_at_beth.k12.pa.us>:
>>>>>
>>>>>
>>>>> On Jan 10, 2012, at 7:45 AM, E.S. Rosenberg wrote:
>>>>>
>>>>>> Hi,
>>>>>> We run a setup where our users are passing through 0-2 proxies before
>>>>>> reaching the Internet:
>>>>>> - https 0
>>>>>> - http transparent 1 (soon also 2)
>>>>>> - http authenticated 2
>>>>>>
>>>>>> Lately we are experiencing some (extreme) slowness even-though the
>>>>>> load on the line is only about half the available bandwidth, we know
>>>>>> that on the ISP side our traffic is also passing through all kinds of
>>>>>> proxies/filters etc.
>>>
>>> So , your ISP does extra filtering? (just to state clear)
>>
>> Yes.
>>>
>>>
>>>>>> I would like to somehow be able to see where the slowdowns are
>>>>>> happening to rule out that it's not our side at fault, but I don't
>>>>>> really know what tool/tools I could use to see what is going on here.
>>>
>>> Have you identify what kind of traffic is slow and what it is not?
>>> This is very important.
>>
>> Most of the traffic is regular http.
>>>
>>>
>>>>>>
>>>>>> We suspect that the slowness may be related to the ISP doing
>>>>>> Man-in-the-Middle on non-banking SSL traffic (as per request of
>>>>>> management), but I really want to rule our side out first....
>>>
>>> This statement is almost impossible, if they were all your HTTPS
>>> conexion will comply about certificate issues. Is that happens?
>>
>> It does, the stations that we control have the ISPs CA installed so
>> they actually don't get warned but wireless clients do.
>>
>> For now we turned of the https filtering and it seems that at least
>> some of the slowness complaints may have been due to unrelated
>> infrastructure problems.
>> But I still would like to know where I can look, we have cacti
>> graphing our throughput so I have an idea of the load on the line
>> itself, we have cachemgr installed on all the proxies but I'm afraid I
>> am not so good at reading&  understanding all of it's output.
>>
>>
>> Regards and thanks,
>> Eli
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Eli
>>>>>
>>>>>
>>>>>
>>>>> Hi eli, are you caching ? or going direct.
>>>>
>>>>
>>>> Hi, sorry for the slow reply.
>>>> We are doing some caching, so far we have not optimized it, Calamaris
>>>> reports our efficiency between 6-10% on different proxies...
>>>
>>> Too low, a good proxy shall give you 30% aprox.
>>>
>>>> Thanks,
>>>> Eliyahu - אליהו
>>>
>>>
>>> LD
>
>
Received on Fri Feb 17 2012 - 01:29:57 MST