> > | > > On Wed, Mar 5, 2008 at 12:59 PM, Mayuresh Kathe wrote: > > | > > > > > | > > > Hi, > > | > > > > > | > > > There's a strange incident that's repeatable on my system > (4.2). > > | > > > > > | > > > Open up Firefox, make it load "www.dilbert.com", then open > another tab > > | > > > and visit any other website, then do the same for 2~3 more > tabs. > > | > > > > > | > > > The first (dilbert) tab takes a long time to load during which > the > > | > > > other tabs too show nothing, they get stuck at "Looking up..." > > | > > > > > | > > > Is it a Firefox problem or something to do with the system?
> > | > On Wed, Mar 5, 2008 at 5:46 PM, Karl Sjodahl - dunceor wrote: > > | > > > > | > > I have seen this on both Windows and OpenBSD. The later firefox > > | > > releases (like from 2.0.0.3-2.0.0.5 something) I have seen > problems > > | > > with having more tabs open. > > | > > I used to have a lot of tabs but now I have restricted myself to > 3-4 > > | > > or firefox is not useable. > > | On Wed, Mar 5, 2008 at 1:18 PM, Mayuresh Kathe wrote: > > | > > > | > I forgot to mention, my Firefox version is 2.0.0.6 > > | > Also I've only got a total of 3~4 tabs open while performing the > Dilbert test. > > | > Taking your cue, I tried an experiment, I opened up 10 tabs, but > > | > without the Dilbert site and all of them opened up in parallel. > > On Wed, Mar 05, 2008 at 01:47:23PM +0100, Landry Breuil wrote: > > | > > | Seems like an ipv6-dns-resolution problem to me. > On Wed, Mar 5, 2008 at 6:50 PM, Paul de Weerd <[EMAIL PROTECTED]> wrote: > > > > > > A bit of background here : > > > > Firefox can do AAAA lookups (for IPv6 addresses) by default for > > websites you visit. Some DNS servers don't like this sort of query > > and, in stead of saying "hey, I dont understand what you want", they > > ignore you in the hope that you go away. Things time out on your end, > > your system will do a A lookup and from there you can continue > > browsing the website. > > > > In the case of the dilbert site, this doesn't seem to be the case. > > Apparantly, one of the NS'en is not responding to queries at all (nor > > ICMP Echo Requests - it's probably down or disconnected from the net > > temporarily). Your caching NS may be trying to contact this one > > nameserver. It'll wait for the timeout and then try one of the other > > NS'en. The problem is exacerbated by the fact that www.dilbert.com has > > a TTL of 300 seconds, so your caching NS doesn't keep this record in > > memory too long. > > > > The problem is that the resolver in OpenBSD isn't reentrant. If it's > > doing nameresolution, it'll not do another one in parallel. So while > > you wait for www.dilbert.com to get resolved (which takes long because > > of this timeout), you open a new tab, enter an address and your > > machine will have to resolve that too, which gets queued up (doesn't > > get handled in parallel), so the other tab also waits on > > www.dilbert.com to get resolved. > > > > You can test this hypothesis by going to a website by its IP address. > > Try visiting http://129.128.5.191/ (http://www.openbsd.org/) while > > you're waiting for www.dilbert.com to load. Visiting by IP should work > > (as it doesn't require a DNS lookup). On 05/03/2008, Mayuresh Kathe <[EMAIL PROTECTED]> wrote: > > Paul, I tried your idea of starting up www.dilbert.com and then > visiting http://129.128.5.191/ (the openbsd website). > It worked as you'd predicted. > So I guess its the problem with the OpenBSD resolver. If you're not able to code a parallel/reentrant DNS resolver for OpenBSD (I'm not), then here's a possible partial workaround: The Dilbert site carries heavy advertising. You can use the Ad Block Plus Firefox Add-On to diable the ads. You may wonder how blocking Ablobe Flush ads helps with a DNS resolution problem. Well, the reason this works is that most ads these days are included from advertisement agencies **which use their own domains**. So blocking these domains not only saves you all that Flash garbage (which also incidentally eats up clock cycles like candy), it also saves you from having to look up the agencies' domain names in the first place. When I visit Dilbert with ABP enabled, the following filters are actively blocking flashvertisements: *.247realmedia.com/RealMedia/ads/* *.advertising.com/* *.adsonar.com/* So in case of dilbert.com, with an appropriate blocklist, 247realmedia.com, advertising.com and adsonar.com are never resolved = no attempted IPv6 lookup attempt for them = less slowdown. NB: As for the number of open tabs, Firefox 2.0.0.x is a real sieve when it comes to memory. It leaks and leaks and leaks... The upcoming Firefox 3 is reportedly going to be a major step forward, but I haven't tried it yet. The desktop machine I'm currently using runs Ubuntu, so this may or may not be directly comparable, but in my experience Firefox 2.0.0.x **can** still be used with >20 tabs spread over 6 windows -- IFF you throw truckloads of RAM at it (e.g. 1-2GB), and use a very comprehensive ABP filter list, and pkill firefox and restart&restore it at least once a day (Firefox 2 allegedly doesn't free memory when tabs are closed). If you want, I can email you my entire ABP filter/blocklist, which you can then import into your ABP. I will send it off-list by default, but if people feel that I should send it to misc for the benefit of the archives, I can do that as well. YMMV, but I hope this helps. Thanks and regards, --ropers
