Chromium

Fixed, by disabling DNS Prefetching.

This summary should be changed to "DNS Pre-fetching causes 'Resolving Host' to take a
long time"

I can confirm this behaviour on Mac 3.0.189.0

For me the resolution takes ages regardless of the setting, though enabling pre-
fetching makes it a lot worse (using 2.0.172.33 currently). Other browsers (tested only
MSIE and Firefox) happily churn away while Chrome nearly hangs itself on this.

Another thing: I see the resolving host for almost each access of the same website even
when there's only <15 second pause between requesting the pages (this before any
content gets drawn or even the page title shown, so it must be resolving the same DNS
over and over again).

I have encountered this bug today on Google Chrome 4.0.222.5 on Ubuntu. Perhaps
there's a regression?

Same problem here, 10+ secs wait on resolving host... 4.0.223.5 on Ubuntu 9.10 rc

I'm using Ubuntu Karmic RC with Chrome right now and haven't experienced an problems.  
Shikakaa and Edwardgtxy, do you guys both have DNS pre-fetching off?

Thanks for your reply, I did disable DNS Pre-fetching and it's much better, but still
pretty bad compare to firefox or ie on windows, maybe it's just something wrong with
ubuntu's domain name to ip caching itself, since I realized firefox has a similar
issue. When I went for dinner, then came back after 1 hr, and it takes both firefox
and chrome 8 secs to do DNS requests on google.com

Ya, isn't that exactly what I've been telling people.  I think that's where I read it,
too. =)

Except it doesn't really fix it, just makes it happen less often.

It fixed it for me.

My /etc/resolv.conf looks like:
# Generated by NetworkManager
domain domain.actdsltmp
search domain.actdsltmp
nameserver 192.168.0.1
nameserver 206.63.24.6

wtc/jar, I'm heard this report pretty frequently lately.  I've also heard that
disabling HTTP scanning in antivirus programs can help (see e.g.
http://www.google.com/support/forum/p/Chrome/thread?
fid=65d1396a4116d3ac000478641e0e75b8&hl=en ).

What kind of info would help track this down?

The resolutions are now going through a chrome resolver module.  I think Eric might
have some stats gathering in that module, and those may provide clues.  I've added
him to the cc list to see if he can offer suggestions.

One thing that would be interesting to look at on a machine having trouble is the:

   about:histograms/DNS

page (just type this into you URL bar).  If one (or more) of the folks having this
problem could visit that internal page, download (or cut/paste) into a text file, and
attached it to this bug, that would be quite informative (putting it as an attachment
will keep from cluttering the bug).  That should at least show what the DNS latency
is looking like, for both prefetching and some of the regular resolutions (for
Navigation).

Sounds like the extra contention caused by DNS prefetch is slowing down the regular
lookups.

Also relevant, it seems we start the prefetch resolutions _before_ starting the main
resolution (since the observer hooks in before starting the resolve). Perhaps we should
delay by some amount of time before starting the prefetches to reduce the load.

To be clear, is this "extra contention" issue one that would be new/worsened by the
resolver module jar mentioned?  I never used to see this bug report on Chrome 1/2, but
I myself may have run into it for the past month or so on the dev channel.

There are imaginable ways that DNS latency may be key, or it may be that some
tangential related problem is causing the delay.  We have (in the past) seen cases
where unusual setups (example: a 5MB etc/hosts file that was being scanned often)
that induced problems, and we tried to put in back-off measures that cause DNS
prefetching to detect latency, and diminish its activity.  The first thing to do is
look at actual numbers, and try to see if it is measurable DNS latency, and the
about:histograms/DNS should provide a lot of objective data.  If you are seeing this
overall delay consistently, please attach a snapshot of that internal page, and it
will help us direct our efforts.

Having seen "remarkable configurations," it is very believable that disabling
prefetching in those cases may help.  Given that it does not significantly help in
some cases, I'm sure there are several issues involved.

It might be interesting to (on the same machine) run two instances of chrome, one
with, and one without prefetching enabled (you'll need two separate profiles).  This
could hint to us as to whether the OS, or LAN connection is starting to slow, or if
the instance of chrome is getting lethargic.  Keep in mind that IF you're visiting
the sames sites in the two instances, then the OS will tend to cache DNS records, and
the "second browser" to navigate will get a lot of benefit (even if it has DNS
prefetching disabled).  

Thanks in advance for providing some specific info.

For those that reproduce this, can you try running (with prefetch enabled) using this custom build:

http://dl.getdropbox.com/u/890462/chromium/chromium-with-logging.zip

(1) Download the above
(2) Extract the zip
(3) Exit running instances of chrome
(4) Launch my version of chrome.exe which you just downloaded
(5) Reproduce the slowness
(6) Exit chrome

There will be a file called "chrome_debug.log" in the directory that contains chrome.exe.

Please upload this file; the lines of interest I care about contain the word "XXX".



If you couldn't reproduce the slowness using this instrumented build, then its probably because my instrumented build is not
using your chrome profile.
In this case, please additionally do these steps:

(1) Make a copy of your chrome profile (http://dev.chromium.org/user-experience/user-data-directory)

On windows XP this means you copy:
   C:\Documents and Settings\<username>\Local Settings\Application Data\Google\Chrome\User Data
to:
   c:\tmp\copy-of-profile

(2) Launch the attached "chrome.exe" with the command-line flag:
  --user-data-dir="c:\tmp\copy-of-profile"


Thanks.

Pages take forever long to load. Resolving host.

Unfortunately there's no bug catching calls for pages that load slow but below is
what I found while running.

system:

[user@localhost ~]$ uname -a
Linux localhost.localdomain 2.6.31.6-162.fc12.i686 #1 SMP Fri Dec 4 01:09:09 EST
2009 i686 i686 i386 GNU/Linux



[user@localhost ~]$ google-chrome -g --sync
[14381:14431:71187095169:ERROR:/usr/local/google/home/chrome-eng/b/slave/chrome-
official-linux/build/src/chrome/browser/password_manager/encryptor_linux.cc(40)] Not
implemented reached in static bool Encryptor::DecryptString(const std::string&,
std::string*)
[14381:14431:71187096821:ERROR:/usr/local/google/home/chrome-eng/b/slave/chrome-
official-linux/build/src/chrome/browser/password_manager/encryptor_linux.cc(40)] Not
implemented reached in static bool Encryptor::DecryptString(const std::string&,
std::string*)
[14381:14431:71187300066:ERROR:/usr/local/google/home/chrome-eng/b/slave/chrome-
official-linux/build/src/chrome/browser/password_manager/encryptor_linux.cc(29)] Not
implemented reached in static bool Encryptor::EncryptString(const std::string&,
std::string*)

(exe:14478): Gdk-WARNING **: XID collision, trouble ahead

(exe:14478): Gdk-WARNING **: XID collision, trouble ahead

Disabling prefetching fixed it for me.

about:DNS says" Dns Prefetching is disabled."
Google Chrome   4.0.249.30 (Official Build 33928)
WebKit  532.5
V8      1.3.18.15
User Agent      Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/532.5 (KHTML,
like Gecko) Chrome/4.0.249.30 Safari/532.5

Unbearably slow. Sometimes I get complaints about DNS error... but Opeara pulls
pages fast. Please see my archive.
http://sites.google.com/site/lifewithfedora12/home/all-animated-gif

http://sites.google.com/site/lifewithfedora12/home/all-animated-gif/chrome_slow.gif?
attredirects=0

bbc loads fast
cnn not at all

You can see in the network monitor zero activity

@tudor prodan:

Can you verify what version of Chromium you were using when "disabling prefetching"
fixed it?  I landed something, in the last week or two, to re-order prefetching of
subresource resolutions, to assure that they didn't start until at least the top-
level navigation resolution was complete.  I believe that fix shipped in last week's
dev channel Chrome, and possibly in the beta's.

Thanks,

Jim

Labels Update:

Replace Area-BrowserBackend by Area-Internals

If things look A-ok on the next Dev channel release we should consider moving this
change into 4.0.

@anand.sharma

I believe there is a change that made it to the dev channel, but has not yet propagated
to the beta channel, and that may (possibly) help with the issue.  Again, data is
helpful, and verifying that you *currently* see a problem that is resolved by disabling
DNS pre-resolution would be a good data point (and we can hope it will be sufficiently
corrected by the patch).

@ben.rowland:

I don't have an answer for you yet... but I'll try to ramble on a bit about what is
happening, and what these pages mean.  I'll also ask a question or two, and suggest
you possibly try google's public dns service.

The about:dns page suggests that it is only www.google.com and www.google.co.uk that
are being visited.  My guess it that you have the latter as your home page, and it
pulled some resources from www.google.com, but that is all you had done so far in
this session.  I'm guessing you sent this set of files because it was THIS session
that produced the bothersome pause.

The second file provided details for all the pre-resolutions performed so far in this
session.  It indicates that a total of 13 names had been pre-resolved (probably 10
from a startup list, and 3 from scanning the startup page(s)).  Apparently 8 of the
resolutions took under 118ms (4 in about 40 ms, 2 in about 55ms, 1 in 75ms and 1 in
about 100 ms), but there were 5 that took between 4.5 and 6 seconds!  5 seconds is a
very big number, and might mean that after resolving 8 names in rapid succession,
that your resolver suddenly decided to take its sweet time.

The pre-resolution start-up code maintains a list of no more than 10 domains to load
at startup.  Chromium also avoids pre-resolving more than 8 names at any one time
(holding other pre-resolutions in a queue as needed).   Based on the DNS.PreftchQueue
time, I can see that nothing sat very long in the prefetch-queue (max was about 190
ms.)  The fact that 18 entries had queuing delay time, but there were only 13
resolution timings just meant that duplicates (in a very small time frame) were
discarded, or that some resolutions took under 15 ms (and were considered cache hits,
not worth timing).

Linux doesn't generally have any DNS cache at the OS level, and so it was probably
your firewall that was providing an intermediate resolver, although it might be that
you were directed to your ISP's resolver.  You might run "nslookup" from a command
prompt, and see if the resolver in use is on your lan, or it is at a routable address
perchance at an ISP.  If it is at your ISP, I'd be very curious to see if Google's
recent public DNS service http://code.google.com/speed/public-dns/  could help you.  
If the problem appears at a resolver in your firewall (on your lan), it would be nice  
if you posted the name/version/etc. for your router/firewall, so we can see if there
is any pattern detected about folks experiencing this problem.

@ben.rowland:

Can you post what broadband router you were using, and what rev of firmware it had?

Right, and I wanted to add that I turned DNS-prefetching back on, on my Mandriva 2010
computer, and it seems to work fast.  Note: I was not using the Google Public DNS
servers.

I reconfigured and started using the Google public DNS, and it seems even faster.

@ jordonwii:

Can you indicate the Chrome version you're running with now that the problem seems
resolved for you?  If you're running the tip-of-tree, then it would be fine to indicate
when you pulled for your build.

Thanks!

I'm using Google Chrome 4.0.266.0

For Ubuntu users and jar@, you might find this interesting:
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/417757

I don't have time to reread it right now but my vague recollection is that Ubuntu has
made some local patches in this (the DNS area) that please some users and anger
others.

@evan:  EXCELLENT reference link!  I believe this bug has "two lifetimes," (causes?)
and the re-incarnated (second cause) appears in the above timeline to have appeared
in October 2009 (see above).

My brief summary of the referenced bug is that around October 2009 some Linux
distributions started supporting IPv6 more aggressively.  Unfortunately, that support
required them to ask for "AAAA" records, which many resolvers didn't understand...
and worse yet, simply discarded!  This then lead to timeouts in the OS, followed by a
retry to get an A record (which does then work).  There was some discussion about how
this works on Windows 7 out-of-the-box, but it does not work on several linux
distributions.  If I understand the final resolution (which was seemingly rolled out
in January 2010), the distribution now detects lack of plausible support for IPv6,
and in such cases, avoids the problematic (high latency) request for AAAA records.

They mentioned that some other distributions of Linux also were aggressive with this
IPv6 support, **BUT** those distributions disabled IPV6 support in FireFox.  It turns
out that the browser is one of the most user-visible applications, and so this OS
problem was not as remarkable on other (non-Ubuntu?) distributions.  [Even though it
was seemingly greatly impacting other apps as well on all such distributions!]

Stepping back, it is easy to imagine that if every DNS resolution took 1 second
(minimum), then many pages would load very slowly.  For example, the first second
might delay getting the outer most frame, and then a resolution of a sub-resource
domain may stall the process for another second, etc.  It is very believable that a
very bad (slow) user experience would result... and every time one host resolution
completed, another would start, and the little message box would show a constant
"resolving host" message.

One intermediate fix was to "use a better ISP resolver."  This included Google's DNS
resolver, among others.  That did avoid the problem (found in many firewall
resolvers, as well as some ISP resolvers).

I'd suggest that folks upgrade to the newest Linux OS distribution, and see if that
fixes the problem.  As a work-around, if you're tech-savvy, you could try to point
your OS at a better resolver, but as noted in the referenced bug, this is a painful
and NON-user-friendly work-around.

The bug has a specific "test" to see if your system is messed up.  They suggest the
following command sequence:

  To verify this, do a:
for i in `cat /etc/resolv.conf | grep ^nameserver | cut -f2 -d' '`; do dig @$i
www.microsoft.com AAAA; done

  This should return quite quickly, even though no AAAA records for www.microsoft.com 
  exist yet. Now, if you have a broken resolver somewhere along the way, these
  requests won't return quickly (unless they are locally or on-path cached as
  negative).

Hopefully we won't have folks that are "not messed up" that are feeling this pain.

Comments from such users?

Is there reason to believe that Chromium should try to (temporarily?) tangentially
help (work-around) by trying to disable IPv6 support (unless a user *demands* it via
some command line option or such)?

> Is there reason to believe that Chromium should try to (temporarily?) tangentially
> help (work-around) by trying to disable IPv6 support (unless a user *demands* it via
> some command line option or such)?

User's in that category can pass the command-line flag --disable-ipv6
I don't think we should change the default behavior.

I am getting a similar issue on Windows 7 - DNS takes a long time (several seconds).
Still happens with IPv6 disabled in Chrome (--disable-ipv6).  I can believe that
something crazy is going on in the network here, but Firefox is unaffected.

Hi eroman@chromium.org,

I have reproduced the slowness, the log is attached. Before reproducing this in the
modified version of Chrome, I tried to disable DNS prefetching, to change DNS servers
(I also tried to change to the Google public DNS) and to reinstall Chrome. Nothing
has helped. I didn't try to disable my second network adapter, because I need it up.
I don't have DNS issues with other applications.

During the test, I launched chrome.exe you have provided, opened a host
http://www.rambler.ru. The browser was frozen on "resolving host" for several
seconds. After that, I opened http://www.hp.com. The same thing there.

Please find the log file attached.

@anthropophag: thanks for running the test!

Using your log file, I plotted the sequence of DNS requests onto a time chart (timeline.html) to visualize what is going on.

Indeed, you are getting EXTREMELY slow DNS resolving... 'www.rambler.ru' took 19 seconds to resolve, and even 'www.google.com'
took 14 seconds [*]!

I was hoping to be able to attribute the slowness to a large number of parallel threads. And while in the repro-case you do reach
17 concurrent DNS resolver threads, the slowness is evident much before this, when there are only 1 to 4 concurrent threads.

I wander if you have some third party software intercepting DNS resolves that is not working well with Chrome. Do you have any
download accelerators / managers, or firewall software, or antivirus software installed? There are some known crashes
ingetaddrinfo() that happen when Chrome runs with Internet Download Manager, so it is possible there could be other sorts of
strange interactions. You can run this command in a windows cmd.exe shell to list out the WinSock layered socket providers:

    netsh winsock show catalog

Thanks!

[*] It is strange that 'www.google.com' was not serviced from cache the second time it was requested, which was only 7 seconds
after the first time...

@anthropophag:

Adding to eroman's questions...

If this is a home-use situation, can you indicate what if any hardware firewall you
have (i.e., your router)?

As another alternative (since you seem game to try things), can you check and see if
a "better" (different??) DNS resolver than your current ISP would help?  Consider
trying to set up use of google's public DNS via http://code.google.com/speed/public-
dns/  
There is a chance that your ISP resolver is misbehaving... which would still leave
open a "why" question, but at least it would clarify if the problem is in/around your
OS, or if it is external.

Thanks in advance,

Jim

@eroman:

the output of net.exe is attached. The last entry (mdnsNSP), which probably is a part
of Apple Bonjour software, looks suspicious.

I performed some additional tests, and that's what I found.

1) Trying to ping an external host causes ping.exe to freeze for 3-5 seconds, just
like Chrome does.
2) When using nslookup, it resolves an external host with less than a second delay.
3) Firefox resolves hosts immediately.

For each test I used the unique domain names to prevent caching.

@jar:

As I already mentioned in my https://crbug.com/chromium/12754#c54, I have tried to use the Google public DNS,
and it didn't help.

Best regards,
Andrei.

Sorry, forgot to answer about accelerators, etc. No, I do not use any accelerators,
download managers, traffic optimizers, etc. At least I think so.

Update.

I killed my Winsock while trying to remove that Bonjour's mdnsNSP. After that I used
the tool named WinSockFix, and now Chrome performs well.

That's sad, because we still don't know the cause of the problem and don't have a
solution. If someone experiencing issues like that (resolving host...) will find this
article, I would suggest him to use WinsockFix in a case of disabling DNS pre-
fetching doesn't help. As far as I know from Google.com, there are many users having
trouble with "resolving host..." problem.

Heh, one more update. After re-installing Checkpoint SecureClient and restarting my
computer, got the same problem. Chrome freezes on "Resolving host...". Will keep
searching. I'll update this post if I'll find something.

FWIW, I have manually set my /etc/resolv.conf to my ISPs nameservers and not the
default my router was giving me. Chromium loads pages fast when I manually set the
nameservers, it takes forever when I use Fedora 12's 'automatic' settings.

I've had this ~5 second "Resolving host.." issue since chromium was available on
Linux. Disabling prefetching had no affect for me, nor did changing name servers. On
my laptop (Arch Linux) it was fine, but my workstation at work (also Arch) had the
dns delay. Thanks to the comments in https://crbug.com/chromium/12754#c50 by jar, I disabled ipv6 on my main
ethernet device, eth0 :

# ifconfig |grep inet6
          inet6 addr: fe80::218:f3ff:fe65:515/64 Scope:Link

# ifconfig eth0 del fe80::218:f3ff:fe65:515/64

and like magic, without having to restart Chromium even, pages began loading
instantly like they did in opera/ff/whatever. I strongly suggest anyone else with
this ~5 second or more delay try disabling IPV6 support on their machine/interface as
it was the long sought after trick for me. Note that this was only happening on
Chromium, so I imagine the DNS lookups are trying IPV6 if it detects an IPV6 address,
which is hitting an internal timout that causes this effect. Note that my network
interface had IPV6 support, the network(s) I'm on do not.

Good luck :)

I am not sure if this might help people but reading this page helped me a lot. Since
everyone was talking about DNS what I did to completely resolve my problem was simple.
I have my computer set for a static IP with a Linksys router. I took the DNS server IP
that the router got from Comcast and I added them to my static IP settings and no more
lag. Actually I was also having a problem where sometimes pictures dont all show up
after the first load and that is also resolved. Maybe someone else can benefit from
this

https://crbug.com/chromium/12754#c65 was mine.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=37776 

------------------------------------------------------------------------
r37776 | eroman@chromium.org | 2010-02-01 16:56:35 -0800 (Mon, 01 Feb 2010) | 10 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/io_thread.cc?r1=37776&r2=37775
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/fixed_host_resolver.h?r1=37776&r2=37775
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver.h?r1=37776&r2=37775
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.cc?r1=37776&r2=37775
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.h?r1=37776&r2=37775
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/mock_host_resolver.cc?r1=37776&r2=37775
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/mock_host_resolver.h?r1=37776&r2=37775
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_resolver_js_bindings_unittest.cc?r1=37776&r2=37775
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/socks_client_socket_unittest.cc?r1=37776&r2=37775
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/url_request/url_request_view_net_internals_job.cc?r1=37776&r2=37775

Add fine grain tracing to HostResolverImpl.

This will help in diagnosing the "slow resolving host" bugs.

Users can now click an "Enable tracing" button on "chrome://net-internals/hostresolver".
This logs detailed information on the DNS requests flowing through the browser (when they were received, when they were posted to the thread pool, when they started running on the worker thread, etc...).

BUG=12754

Review URL: http://codereview.chromium.org/556094
------------------------------------------------------------------------

Thanks. I downloaded rev. 37776, enabled tracing and that's what I did by steps:

1) Opened www.apple.com
2) Opened www.cnn.com
3) Opened www.whitehouse.gov

Each request caused Chrome to freeze 5-10 seconds on "Resolving host..." I'm attaching  
the trace file, hope it will help.

P. S. Both Firefox and IE are feeling well.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=38078 

------------------------------------------------------------------------
r38078 | jar@chromium.org | 2010-02-03 20:07:59 -0800 (Wed, 03 Feb 2010) | 9 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.cc?r1=38078&r2=38077
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_proc.cc?r1=38078&r2=38077
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_proc.h?r1=38078&r2=38077

Turn off ipv6 when there is no support at startup.

IPv6 confusion (attempt to support when it is really
not supported) has been harming performance, and this
may help *some* users that don't have ipv6 support.

BUG=12754
r=wtc
Review URL: http://codereview.chromium.org/564052
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=38083 

------------------------------------------------------------------------
r38083 | jar@chromium.org | 2010-02-03 22:03:41 -0800 (Wed, 03 Feb 2010) | 12 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.cc?r1=38083&r2=38082
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_proc.cc?r1=38083&r2=38082
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_proc.h?r1=38083&r2=38082

Revert 38078 - Turn off ipv6 when there is no support at startup.

IPv6 confusion (attempt to support when it is really
not supported) has been harming performance, and this
may help *some* users that don't have ipv6 support.

BUG=12754
r=wtc
Review URL: http://codereview.chromium.org/564052

TBR=jar@chromium.org
Review URL: http://codereview.chromium.org/574001
------------------------------------------------------------------------

I have IPv6 over IPv4 (Teredo or some such) in use, so I don't know if these IPv6
changes help me or not.

Thank you very much anthropophag for the log file!

Do you get better performance when you disable DNS prefetching?

It looks like in your test, the main DNS resolves are being preceded by some very slow speculative resolutions for non-
existent domains, and this could be slowing down the system resolver.

Specifically here is my analysis of the data.

(1) www.apple.com:

The user typed in a navigation to  www.apple.com. This started by generating two speculative requests:

    www.apple.co    [failed, took 14 seconds]
    www.apple.com   [succeeded, took 7 seconds]

The first speculative request, "www.apple.co" turns out to be a non-existent domain, and it took the system resolver 14
seconds to complete.

The speculative request to "www.apple.com" preceded the actual navigation to 'www.google.com' by 672 milliseconds so
it gave the resolution a half second head-start (good).

However the resolution for 'www.apple.com' still took 7 seconds to complete. It is possible that the in-progress resolve
to "www.apple.co" slowed down the system resolver.

(2) www.cnn.com:

User typed in "www.cnn.com". This triggered three speculative requests in this order:

   www.cn        [failed, took 22 seconds]
   www.cnn.cm    [succeeded, took 7 seconds]
   www.cnn.co    [failed, took 28 seconds]
   www.cnn.com   [succeeded, took 14 seconds]

Clearly, the requests to non-existent hostnames took an extraordinary amount of time before failing.

It seems plausible that the outstanding requests to non-existent hosts (www.cn and www.cnn.co), may have slowed
down the host resolver when we eventually issued the request to 'www.cnn.com'

In fact, there is an interesting correlation between these numbers:

  * When resolving 'www.apple.com', there was 1 doomed resolve in progress, and it took 7 seconds
  * When resolving 'www.cnn.com', there were 2 doomed resolves in progress, and it took 14 seconds.

Sort of a stretch, but it almost looks like the time to resolve valid hosts is 2 seconds * (number of doomed resolves).

(3) User navigates to www.whitehouse.gov

After loading www.cnn.com, there was a flurry of DNS activity (a bunch of speculative too).

So by the time the user navigates to www.whitehouse.gov, there are already 11 outstanding DNS resolves running on
threads.

Of these, 7 are speculative requests.
All of these requests end up taking very long time to complete:

www.fannation.com           [36 seconds; *speculative*]
www.ireport.com             [7 seconds; *speculative*]
www.news9.com               [22 seconds; *speculative*]
www.oprah.com               [15 seconds; *speculative*]
www.time.com                [29 seconds; *speculative*]
googleads.g.doubleclick.net [21 seconds; *speculative*]
b.scorecardresearch.com     [28 seconds]
clients1.google.lv          [28 seconds]
www.google.lv               [41 seconds; *speculative*]
cnn.dyn.cnn.com             [40 seconds]
gdyn.cnn.com                [40 seconds]
www.whitehouse.gov          [46 seconds]

So the the DNS request which we care about, 'www.whitehouse.gov' ends up taking 46 seconds, and is running in parallel
with 11 other resolves.

This is the slowest of the two navigations, taking close to a minute!
It is also the case with the most DNS parallelism.
Seems reasonable to infer that the extra DNS parallelism is hurting the system resolvers performance (it might have its
own internal queue or something like that).

I ran into a bad case of this last week and tried to copy as much information as
possible from about:net-internals

Safari was fine, Firefox was fine, restarting Chrome made everything work fantastic.  I never, ever, ever restart Chrome so I'm wondering if it's somehow related to that.

Sorry if the information isn't very useful... if you have any tips on collecting
better data when I run into this again would be great :)

@scherkus: The most useful data is If you can run a tip of tree build, then you can
capture a DNS request trace by enabling tracing at chrome://net-internals/hostresolver

If you are an mac, it is likely that your bug is http://crbug.com/20471

eroman,

thank you for you answer. I have disabled DNS prefetching and performed the test
again. It worked better, but still too slow. I used another domains, which you can
find in the trace file.

test

I'd like to throw out there, even on the times Chrome does not take forever, DNS
resolving _always_ takes longer for me than on other browsers.  Except, for the most
part, on Chromium OS.  DNS resolving is much faster for me there than on other OS's.  
Maybe that's just me, but...

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=39996 

------------------------------------------------------------------------
r39996 | jar@chromium.org | 2010-02-24 22:42:19 -0800 (Wed, 24 Feb 2010) | 16 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/io_thread.cc?r1=39996&r2=39995
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver.h?r1=39996&r2=39995
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.cc?r1=39996&r2=39995
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.h?r1=39996&r2=39995
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_util.cc?r1=39996&r2=39995

Refine IPv6 probe to require that the client has an IPv6 address on an interface

This currently only works on Posix, not windows.

Network changes are monitored, and the test is repeated each time interfaces
change (which is a subset of any IP addresses changing).

The test performed is still relatively low latency, and we *may* need
to eventually move to an high latency test, such as a DNS resolution,
or an actual test connection.  If we move in that direction, then we'll
need to post a task to perform the work, rather than immediately returning.

BUG=25680
BUG=12754
r=wtc,eroman
Review URL: http://codereview.chromium.org/652072
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=39998 

------------------------------------------------------------------------
r39998 | jar@chromium.org | 2010-02-24 23:40:28 -0800 (Wed, 24 Feb 2010) | 19 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/io_thread.cc?r1=39998&r2=39997
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver.h?r1=39998&r2=39997
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.cc?r1=39998&r2=39997
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.h?r1=39998&r2=39997
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_util.cc?r1=39998&r2=39997

Revert 39996 - Refine IPv6 probe to require that the client has an IPv6 address on an interface

This currently only works on Posix, not windows.

Network changes are monitored, and the test is repeated each time interfaces
change (which is a subset of any IP addresses changing).

The test performed is still relatively low latency, and we *may* need
to eventually move to an high latency test, such as a DNS resolution,
or an actual test connection.  If we move in that direction, then we'll
need to post a task to perform the work, rather than immediately returning.

BUG=25680
BUG=12754
r=wtc,eroman
Review URL: http://codereview.chromium.org/652072

TBR=jar@chromium.org
Review URL: http://codereview.chromium.org/660073
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=40099 

------------------------------------------------------------------------
r40099 | jar@chromium.org | 2010-02-25 21:33:45 -0800 (Thu, 25 Feb 2010) | 29 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/io_thread.cc?r1=40099&r2=40098
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver.h?r1=40099&r2=40098
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.cc?r1=40099&r2=40098
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.h?r1=40099&r2=40098
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_util.cc?r1=40099&r2=40098

Revert 39998 - Revert 39996  Refine IPv6 probe to require that the client has an IPv6 address on an interface

This is a second attempt to land a reviewed change. It was reverted because
the tree got very red (for other reasons), and it was plausible that this
change was causing startup latency in Mac and Linux (causing both perf bots
 to go red).  If this landing turns those perf-bots red (tonight) I'll need
to revert.  (... and I'll need to rearchitect to do the probes
 asynchronously, and get off the startup-critical-path.

This currently only works on Posix, not windows.

Network changes are monitored, and the test is repeated each time interfaces
change (which is a subset of any IP addresses changing).

The test performed is still relatively low latency, and we *may* need
to eventually move to an high latency test, such as a DNS resolution,
or an actual test connection.  If we move in that direction, then we'll
need to post a task to perform the work, rather than immediately returning.

BUG=25680
BUG=12754
r=wtc,eroman
Review URL: http://codereview.chromium.org/652072

TBR=jar@chromium.org
Review URL: http://codereview.chromium.org/660073

TBR=jar@chromium.org
Review URL: http://codereview.chromium.org/661164
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=40101 

------------------------------------------------------------------------
r40101 | jar@chromium.org | 2010-02-25 22:07:25 -0800 (Thu, 25 Feb 2010) | 29 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/io_thread.cc?r1=40101&r2=40100
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver.h?r1=40101&r2=40100
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.cc?r1=40101&r2=40100
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.h?r1=40101&r2=40100
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_util.cc?r1=40101&r2=40100

Revert 40099 - Revert 39998  Revert 39996  Refine IPv6 probe to require that the client has an IPv6 address on an interface

It is indeed causing a perf regression in startup on Linux...
I'll need to rearchitect to do the probes asynchronously, and get
off the startup-critical-path.

This currently only works on Posix, not windows.

Network changes are monitored, and the test is repeated each time interfaces
change (which is a subset of any IP addresses changing).

The test performed is still relatively low latency, and we *may* need
to eventually move to an high latency test, such as a DNS resolution,
or an actual test connection.  If we move in that direction, then we'll
need to post a task to perform the work, rather than immediately returning.

BUG=25680
BUG=12754
r=wtc,eroman
Review URL: http://codereview.chromium.org/652072

TBR=jar@chromium.org
Review URL: http://codereview.chromium.org/660073

TBR=jar@chromium.org
Review URL: http://codereview.chromium.org/661164

TBR=jar@chromium.org
Review URL: http://codereview.chromium.org/660165
------------------------------------------------------------------------

Curious: the problem was reported for Mac and Linux but not Windows.  Windows sets
AI_ADDRCONFIG in the hints for getaddrinfo() by default, the more POSIXy systems do
not.

trunk/src/net/base/host_resolver_proc.cc already sets AI_ADDRCONFIG and has more
commentary on this and the portability thereof.

Perhaps all that's needed is to put AI_ADDRCONFIG into the hints on non-Windows
platforms anywhere that there's a DNS resolution?

AI_ADDRCONFIG was added to the IPv6 sockets spec in RFC 3493 in 2003.  If there's no
routable IPv6 address bound to a local interface, it causes getaddrinfo() to not
query for or return IPv6 results.  (Similarly for IPv4).

I'm experiencing that problem and I'm using Windows.

@rayv24: Your comment is very helpful.  There are (seemingly) numerous ways that
problematic routers/resolvers can cause various flavors of delays when attempting to
resolve a host.  In each case, it is possible to identify the problematic
routers/resolver... but we need to have a clear understanding of how to detect such a
problem (and of course, what to do to work around it). I'm sure you're not alone in
your dilemma, and I'm hopeful we can help others with the same problem.

As I understand your specific problem:

a) An attempt to resolve any IP via your resolver (with IPv6 enabled) gets an
resolution of 1.0.0.0.  Is that the correct "symptom" your problem?

b) One work-around is to disable ipv6 in chrome (I assume that requests for non-IPv6
resolutions work fine).  Is that correct?  Specifically, please verify that starting
up with --disable-ipv6 allows at least Chrome to run even when your buggy(?) router
and busybox is in use.

If I understand that correctly, I should be able to craft a patch that allows at
least your class of problem to be transparently worked-around (when running Chrome).

I should be able to attempt an IPv6 resolution of a well-known site.  If I get back
1.0.0.0, I should assume it was your problem, and automatically disable IPv6.  If it
is anything else (including, host not found), I should conclude at least your problem
is not present (and leave IPv6 support status unchanged).

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=41743 

------------------------------------------------------------------------
r41743 | jar@chromium.org | 2010-03-16 12:06:03 -0700 (Tue, 16 Mar 2010) | 17 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/io_thread.cc?r1=41743&r2=41742
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.cc?r1=41743&r2=41742
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_impl.h?r1=41743&r2=41742
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_util.cc?r1=41743&r2=41742

Refine IPv6 probe to require that the client has an IPv6 address on an interface

This currently only works on Posix, not windows.

Network changes are monitored, and the test is repeated each time interfaces
change (which is a subset of any IP addresses changing).

The test performed is performed on a worker thread, so latency should not
be an issue (even if we created much slower tests).

The current test appears to takes in the raneg of 50-100ms, and probably
(under the covers) does some reading from files).

BUG=25680
BUG=12754
r=wtc,eroman
Review URL: http://codereview.chromium.org/1006001
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=42181 

------------------------------------------------------------------------
r42181 | jar@chromium.org | 2010-03-19 22:41:42 -0700 (Fri, 19 Mar 2010) | 33 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/browser_main.cc?r1=42181&r2=42180
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/dns_global.cc?r1=42181&r2=42180
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/render_view.cc?r1=42181&r2=42180
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_stream_parser.cc?r1=42181&r2=42180

2 experiments: DNS prefetch limit concurrency: TCP split a packet

Some firewalls apparently try to preclude a "syn flood to host" by limiting
the number of syn's (used to open a TCP/IP socket) that are outstanding
without having received a syn-ack.  Presumably this is to prevent a user
from participating in a syn-flood attack (which traditional sends a lot
of syn packets, with false return addresses, resulting in no responses).

Apparently this firewall technology has in some cases been extended
to include UDP sessions for which there has been no response, and this
may include DNS resolutions.  Since the prefetcher currently resolves
as many as 8 names simultaneously, this is remarkably close to the
reported threshold of 10 un-answered connections.  This test attempts
to limit connections to 2, 4, or 6, so that we can see if this helps
users.

In TCP, the RTO remains (under windows) at a full 3 seconds until after the
first ack is received.  As a result, if the first data packet sent (after
the SYN) is lost, then TCP won't resend until after 3 seconds without an ack.
As a test, we split up the first packet into two parts (the second part
containing only one byte).  This is done as an A/B test, and we'll see
if we get a measurable improvement in page-load-time latency.

Finally, to get better page load stats, I adjusted the PLT histograms
so that we record a "final" time for abandoned pages when they are
closed (even if they didn't finish rendering, etc.).  This should give
a much more fair PLT comparison for all network latency experiments.


BUG=3041
BUG=12754
r=mbelshe,darin
Review URL: http://codereview.chromium.org/1088002
------------------------------------------------------------------------

[Empty comment from Monorail migration]

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=42544 

------------------------------------------------------------------------
r42544 | jar@chromium.org | 2010-03-24 14:58:31 -0700 (Wed, 24 Mar 2010) | 18 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/io_thread.cc?r1=42544&r2=42543
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_util.cc?r1=42544&r2=42543

Add IPv6 probe support for Windows

This is meant to test to see if AI_ADDRCONFIG is doing its
job in windows, or if we have to do the scans when there is
a network change.

Also switch to always doing probe support on Mac/Linux platforms.
There appears to be (on aggregate) around a 40% degradation of
DNS resolution times on the Mac, and about 17% degration on
Linux, when we don't probe.  It is likely that a few users
are greatly impacted by this, and are able to move the average
of the whole user population.


BUG=12754
BUG=25680
r=wtc
Review URL: http://codereview.chromium.org/1210003
------------------------------------------------------------------------

Hey Jim,

Could you summarize the status of this bug?

Status summary: At least one of the causes was improper handling of IPv6
configuration and DNS resolution by a combination of the OS, and the external
resolvers.  We've patched this (in the tip-of tree as of r42544), to do the detection
better (than the OS) on Mac and Linux, and are now testing to see if the Window's
handling of AI_ADDRCONFIG is also flawed (i.e., the probe would help there).

This may not be the ONLY cause of long resolution times, but it is surely one of
them.  I expect that the newest Google Chrome Dev builds going out this week will
help Linux and Mac users a lot.... and then we'll have to see how much of a problem
remains.

We'll also find out this week (from a test) if some Windows users are having the same
problem.

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

ukjent.navn: I suggest you file a new bug, since DNS prefetching doesn't seem to affect you.  In it, you should
post the contents of the chrome_debug.log (http://dev.chromium.org/for-testers/enable-logging) and
chrome://net-internals.

Also, one thing to note is that when you switch to using VPN (or unplug/replug the wire, switch to wireless or
wired, etc), Chrome will notice this and flush some of its internal network state.  Is it totally fine while you stay
on VPN?

Please put all this information in a new bug.

ukjent.navn: Is it possible for you to log into your ADSL modem (router? firewall?)
and see if there is an option to "block syn flood attacks?"  Perhaps when you're not
using the VPN, your individual connection rate is triggering the firewall to block
you (especially since you indicated that you're sharing use of the line).  In
contrast, when you have a VPN connection, perhaps all your traffic is routed (safely,
and consistently) through one open connection.

A second set of questions is: How long do you remain "disconnected?"  Is it a matter
of seconds? minutes? or does it require a reboot of the ADSL modem? Does it block
connections to all sites from your Chromium? or just a specific site that "triggered"
the problem?  Does it simultaneously block internet access from other browsers on
your same computer?  Does it block access to all users of your ADSL line?

[Comment Deleted]

I am on 64 bit Windows 7 and Chrome 4.1.249.1045 (42898). I was on a cable internet
provider(Time Warner of NY) and router(Linksys) and I never saw this issue. I have
since moved and switched to a different cable internet provider(Comcast of NJ) and
router(Belkin) and immediately began seeing this issue very consistently. Sometimes
the page itself would fail to load, but much more frequently the page would load, but
the page's assets or some of them would fail to load. The messaging was always
resolving host or somehow related.

In my case, disabling DNS pre-fetching immediately resolved the issue without the
need for any other steps. I am reporting this because in my case, I am apt to believe
it is somehow directly related to the ISP, although it is certainly possible the
router is part of the issue as well.

I have no other observable issues with my ISP, online games, bit torrents, and other
browsers all seem to function properly.

@ironcrutchli:  Any chance you could try to do the steps I listed in https://crbug.com/chromium/12754#c97 
above?  It would be VERY helpful if I could gather info from some reproducible
problems, and it sounds like you could really help.

Also, you mention "the page itself would fail to load, ...".  What are some precise
examples of pages that you're having trouble with?

Thanks,

Jim

I get this issue as well; very intermittent... sometimes no problems, sometimes affects
all browsing in a span of 5-10 minutes.  ONLY a problem at home on DSL, not at work
on high-speed LAN (big pipes, something).

@ten.photos: Are you using the same machine (laptop?) at home and work, or is it a
different machine?  

With regard to the home configuration, can you try to do the steps I listed in
https://crbug.com/chromium/12754#c97 above?  I'd like to gather details about home routers that seem to be
involved in this problem.

Thanks,

Jim

I had the same problem on Windows XP using Google Chrome 4.1.249.1064.

It seems I solved it successfully by deactivating the virtual network interface
"VirtualBox Host-Only Network" that was installed by VirtualBox.

This does not seem to be a Windows problem, since other browsers (eg. Firefox) had no
problem resolving host names quickly.

@jar: Am I correct in thinking that your revisions are in the current 5.0.375.28 dev
linux release?

I'm still seeing this problem on about 50% of pages.
I know my router doesn't support IPv6 DNS correctly.

I've attached my trace file.

Hi!
I'm using Chrome 5.0.375.55 on Windows XP3 and am experiencing the "resolving host"
issue intermittently but frequently. I also have Firefox 3.6.3 on the same PC and
there aren't any problems with that browser.

I have PCTools Firewall Plus (free) 6.0.0.88.

I have disabled DNS-prefetching in Chrome to no avail.

My hosts file is tiny (less than 100 entries). I'm sorry I can't give any other
helpful technical information.

I had the same problem, delays while "resolving host". I managed to figure out the
problem on my side. It turns out my problem wasn't so much with DNS resolution but
with another name resolution service, namely WINS.

To be able to resolve WINS names of Windows computers on the network, I changed a
line in /etc/nsswitch.conf from:
hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4
to
hosts:          files wins mdns4_minimal [NOTFOUND=return] dns mdns4

That's what broke my internet name resolution. I replaced the line with the original
and now Chrome's as speedy as ever.

See also:
http://www.uluga.ubuntuforums.org/showthread.php?p=9386520

Coincidentally, before I figured out this problem, I tried out Firefox to see if it
had the same problem, but it didn't.... well, not very noticeably. Not sure why that
is.

I realize this probably doesn't help most of the people encountering this problem,
but hopefully it'll help some.

Also been happening to me for months, whether using latest Dev version of stable version for Mac 10.6. New
pages say resolving host for several seconds before anything is actually loaded. Probably does not exist in Firefox
or Safari. Disabled DNS prefixing. Hope this issue is resolved soon, but luckily it looks like Safari 5 will be
announced Monday!

[Empty comment from Monorail migration]

Moving to Mstone-X, as most all reported problems seem to go away (and not be related to DNS pre-resolution) after closer investigation.

I'll leave this open for a while to respond to suggestions that pre-resolution may be causing a problem.

What does moving to Milestone-X mean? This is a serious issue, as can be seem but scrolling through the plethora of comments above. Disable the DNS Prefetch setting does not help. Works fine in all browsers except Chrome, this is a Chrome problem. Have tried on every Mac at the office as well as at home.

Though changing your DNS to Google's 8.8.4.4 may reduce or resolve the problem, not everyone can change that such as people in a work environment who need to connect to local equipment by name.

Please continue to work to fix this as soon as possible.

For this still experiencing this, could you experiment with different number of DNS threads in Chrome?

To do this, please launch Chrome using the flag:
   --host-resolver-parallelism=XXX

(This is available in Chrome 6 and later).

By default Chrome will be implicitly using:
  --host-resolver-parallelism=50

To make Chrome behave more similarly to Firefox, pass the flag:
  --host-resolver-parallelism=8

(Although the prioritization for prefetch requests will still differ).

It would be helpful to hear whether lower values of --host-resolver-parallelism are improving your load times, and specifically what values worked/which didn't.

Some debugging of a problem on the dns-operations list by someone with a particular home router strongly suggested that the box had a limited number of entries in the state table available for UDP flows and that aggressive DNS on the client, such as by an IPv6-enabled browser which does pre-fetching, was sufficient to overflow the state table and lead to timeouts.

Note that for this setup, the DNS recursor was on a client box behind the NAT gateway, so that the gateway was passing on traffic; I believe it's more common for the gateway to either provide DNS itself, or pass through traffic to an external recursor, so the number of flows is limited.

Thread starts in: https://lists.dns-oarc.net/pipermail/dns-operations/2010-September/006119.html

Perhaps an avenue worth investigating, and perhaps Chrome could be less strident in its DNS pre-fetching?

@syscomet (116) -- I believe this is the source of my previous problem. The 2wire router has a DNS server builtin, and it uses this by default. After replacing this hardware, my issue disappeared. This is a fairly common piece of hardware. It's possible that many of the above issues are related.

I was experiencing the same thing on a Mac at home last night behind a 2wire router.

@uconnhuskiesfans:  The options listed are command line options used to first start Chromium.  The most common way to set them (on Windows) is to edit the "Properties" of the startup icon (right click on he icon), and edit (add to) the startup line the *exact* command line switches.  There is a similar approach on Linux, and I've heard it is more complicated on the Mac.

I'm running Chromium 5.0.359.0 (0) on OpenBSD 4.8. The problem is mostly resolved for me when I remove the search line from /etc/resolv.conf. I did not experience the problem at all on a similar system that never had a search line in /etc/resolv.conf. Pref-fetching is still enabled.

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

about:settings -> advanced -> disable predict network actions

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

A change has landed for this issue, but it's been open for over 6 months. Please review and close it if applicable. If this issue should remain open, remove the "Hotlist-OpenBugWithCL" label. If no action is taken, it will be archived in 30 days.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This is really old - but assigning to csharrison as he is experimenting with disabling preresolve/preconnect to see what impact is particularly on poor networks.

[Empty comment from Monorail migration]

This bug is several years old, and the relevant systems have all changed a lot since the last meaningful activity, so I'm going to archive it. Anyone still experiencing the problem is welcome to file a new bug.

This issue was migrated from crbug.com/chromium/12754?no_tracker_redirect=1

[Multiple monorail components: Internals>Network, Internals>Network>DNS]
[Monorail mergedwith: crbug.com/chromium/14228, crbug.com/chromium/28943]
[Monorail components added to Component Tags custom field.]