RE: [squid-users] Some pages loading very slow in 3.1.10 Stable

From: Saiful Alam <saifulmr_at_hotmail.com>
Date: Tue, 25 Jan 2011 17:17:30 +1100

As advised earlier, I have disabled ipv6 support while recompiling squid, but the problem still exist. Do you want me to disable ipv6 in the OS and try again?

Regards,
Saiful

----------------------------------------
> Date: Mon, 24 Jan 2011 18:39:42 -0200
> From: marcus.kool_at_urlfilterdb.com
> To: squid3_at_treenet.co.nz
> CC: squid-users_at_squid-cache.org
> Subject: Re: [squid-users] Some pages loading very slow in 3.1.10 Stable
>
>
>
> Amos Jeffries wrote:
> > On 24/01/11 23:09, Michael Hendrie wrote:
> >>
> >> On 24/01/2011, at 8:17 PM, Saiful Alam wrote:
> >>
> >>>
> >>> OK I have kept your suggestion in my mind, but right now I'm not in
> >>> a position to buy two HDD's. May be I can afford to buy 15 days
> >>> later. For the time being, my prime problem is the loading of two
> >>> major sites from where my users download mp3. Those are
> >>>
> >>> www.music.com.bd and www.djmaza.com
> >>>
> >>
> >> Seems to load fine for me but that doesn't mean your slow = my fine.
> >>
> >> I had issues with some random sites being "slow" with 3.1.10 and
> >> tracked it down to squid trying to get AAAA records for the problem
> >> sites (or objects pulled from other sites). Not sure why this was
> >> occurring as IPv6 is not enabled on the OS. I didn't investigate too
> >> much and just recompiled with --disable-ipv6 as it wasn't needed.
> >> Doing so resolved my slow sites issue.
> >>
> >
> > Seems like you actually had IPv6 partially enabled in the OS, and maybe
> > a break in DNS or MTU.
> >
> > When Squid 3.1.10 starts up it probes the OS network capabilities to see
> > if IPv6 connections can be made. When they are possible it enables
> > things like AAAA to use those connections. --disable-ipv6 merely sets
> > the result of that test to always be false.
> >
> > With a reasonably fast DNS response time (under a half second) AAAA
> > lookups will not be noticeable.
>
> I am one of those who live in Brazil and most lookups are slow
> since the international lines from Brazil to the USA are
> not properly sized.
>
> The log of the DNS server shows that the lookup for the A record is
> always preceded by the lookup of the AAAA record.
>
> What is the point of doing AAAA record lookups and trying to use the result
> and then reverting to A record lookups and succeeding with the connect() ?
> It is a lot of overhead for systems connected to slowish WANs and
> systems with *many* connections.
> The latter category might get a performance increase if Squid
> automagically detects that there is no IPv6 router or uses
> a new configuration option 'network_has_ipv6_router'.
>
> I did not find options to configure bind/named to ignore AAAA lookups either
> so I would love to see Squid have the new option.
>
> > With working MTU there will be almost zero lag from opening and
> > attempting IPv6 connections on an IPv4-only network.
> >
> >>
> >>> Don't know the reason, but music.com.bd loads very slow. And in
> >>> firebug i see that the problem persists while loading 3 ads from
> >>> ads.clicksor.com and some facebook widgets. Can you please check
> >
> > There you have the problem by the looks of it.
> >
> > Ad servers are very bad for being slow. They usually do a lot of
> > processing or slow operations in the background before replying. Due to
> > their tracking desires they do not permit proxies to cache and speed up
> > their results. Some are more noticeable than others.
> >
> > Facebook is designed in a similar way which also suffers from these
> > heavy processing delay problems on the APIs. But they do seem to be
> > emitting useful cache controls on the static bits to avoid that.
> >
> > You have a choice:
> > put up with it
> > or
> > block those URL from being fetched.
> >
> >>> and try to load these two domains if you're running a Squid 3.1.X
> >>> version and see if everything is alright from your end.
> >>>
> >
> > Amos
                                               
Received on Tue Jan 25 2011 - 06:17:37 MST

This archive was generated by hypermail 2.2.0 : Tue Jan 25 2011 - 12:00:03 MST