New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slow installation starting with v2.2.0 #1017

Closed
toy opened this Issue Sep 17, 2014 · 21 comments

Comments

Projects
None yet
@toy
Copy link
Contributor

toy commented Sep 17, 2014

Following script and its output show that time went from ~5s for v2.1.11 to 1m28 for v2.2.0 and ~2m32 for v2.4.1:

for version in 2.1.11 2.2.0 2.4.1; do
  update_rubygems _"$version"_ > /dev/null
  gem --version
  time gem install image_optim
done
2.1.11
Successfully installed image_optim-0.16.0
1 gem installed

real    0m4.888s
user    0m2.051s
sys 0m0.174s
2.2.0
Successfully installed image_optim-0.16.0
1 gem installed

real    1m28.511s
user    0m3.557s
sys 0m0.314s
2.4.1
Successfully installed image_optim-0.16.0
1 gem installed

real    2m32.421s
user    0m0.338s
sys 0m0.100s

Running gem install with --debug shows that starting with v2.2.0 there are Resolv::ResolvTimeout errors rescued.

Checking source got me to Gem::RemoteFetcher#api_endpoint which uses resolving and Gem::Source#api_uri which was not used before v2.2.0.
Following code takes around 1m15 to fail:

require 'resolv'
Resolv::DNS.new.getresource '_rubygems._tcp.rubygems.org', Resolv::DNS::Resource::IN::SRV
@databus23

This comment has been minimized.

Copy link

databus23 commented Sep 23, 2014

I'm seeing something similar on a rhel Vagrant VM with VMware Fusion.

Are you running on linux? Can you check if you have search localdomain in your /etc/resolv.conf?

In my case the timeout goes away as soon as a remove localdomain from the search domains in /etc/resolv.conf

@toy

This comment has been minimized.

Copy link
Contributor

toy commented Sep 23, 2014

@databus23 For me this happens on osx.
I don't have search localdomain in /etc/resolv.conf, but as I know dns resolving in osx doesn't work exactly as in linux.

@drbrain drbrain added this to the 2.5 milestone Sep 23, 2014

@drbrain

This comment has been minimized.

Copy link
Member

drbrain commented Sep 23, 2014

It is fast for me:

$ time ruby -rresolv -e "Resolv::DNS.new.getresource '_rubygems._tcp.rubygems.org', Resolv::DNS::Resource::IN::SRV"

real    0m0.089s
user    0m0.071s
sys     0m0.010s

Same as for using host:

$ time host -t srv _rubygems._tcp.rubygems.org
_rubygems._tcp.rubygems.org has SRV record 0 1 80 api.rubygems.org.

real    0m0.008s
user    0m0.003s
sys     0m0.003s

My resolv.conf is ordinary, after stripping the OS X comments:

domain jijo.segment7.net
nameserver 10.101.28.65

Can you provide more information about your environment? Is it only slow with Resolv::DNS, or does host take just as long? Does it work faster with the 8.8.8.8 DNS server? Is their anything unusual in your local DNS configuration?

@toy

This comment has been minimized.

Copy link
Contributor

toy commented Sep 23, 2014

@drbrain Thank you for suggestion, I've though about trying Google DNS, but did it only now and resolving works and it is fast (after checking a bit more it seems to be an issue with ADSL modem as using DNS of provider directly also works).
Though it may be better to help/warn in case of problems: reduce resolv timeout and warn user if timed out. Maybe an argument to gem isntall to skip this step?

@drbrain

This comment has been minimized.

Copy link
Member

drbrain commented Sep 24, 2014

The query is how RubyGems figures out how to talk to the rubygems APIs for fetching gems so it can't be skipped.

If you can provide information that helps us figure out the problem then maybe we can resolve this properly

@toy

This comment has been minimized.

Copy link
Contributor

toy commented Sep 24, 2014

@drbrain But it still works for previous versions of rubygems which do not resolve api host and it works for current version after failing to resolve api host. If such behaviour is going to be deprecated on rubygems.org side then I understand why it can't be skipped.

I am not sure what information I can add: if for some reason SRV resolving fails then it takes considerable amount of time (75 seconds) without any feedback (unless in debug mode) though gems will be successfully installed.

@drbrain

This comment has been minimized.

Copy link
Member

drbrain commented Sep 24, 2014

The lookup is for forward-compatibility with future versions that may move where the API is hosted.

Your DNS server, speed of host command, anything unusual in your DNS configuration (compared to mine) would all be helpful. If this is a problem with your ISP only (host and Resolv::DNS each take the same amount of time) then you should report it to your ISP.

toy added a commit to toy/rubygems that referenced this issue Sep 24, 2014

Warn if getting SRV record fails, part of rubygems#1017
Feedback in case of problems with DNS configuration which can cause long timeout
@toy

This comment has been minimized.

Copy link
Contributor

toy commented Sep 24, 2014

@drbrain Problem is not with my ISP but with my ADSL modem/router which does not properly work as DNS relay in default mode (automatic discovery).

This caused both host and Resolv::DNS fail, timeout is different: 10 seconds for host and Resolv::DNS tries four times with increasing timeout (5, 10, 20, 40).

Please have a look at #1023.

@drbrain

This comment has been minimized.

Copy link
Member

drbrain commented Sep 24, 2014

Maybe I can configure Resolv::DNS to use different timeouts then. I will look into this so that when it fails it at least doesn't take as long.

@databus23

This comment has been minimized.

Copy link

databus23 commented Sep 24, 2014

So something is different when looking up SRV records compared to other DNS records when search localdomain is in the resolv.conf:

> time host _rubygems._tcp.rubygems.org
Host _rubygems._tcp.rubygems.org not found: 3(NXDOMAIN)

real    0m0.032s
user    0m0.001s
sys 0m0.003s

> time host -t SRV _rubygems._tcp.rubygems.org
;; connection timed out; no servers could be reached

real    0m10.055s
user    0m0.002s
sys 0m0.003s

This makes no sense to me.
I tried figuring out with strace what is going on but couldn't make sense of the output.

@drbrain Whatever the problem is with looking up SRV records your suggestion to modify the timeouts is probaply the best way to ensure its not hanging for 60 seconds or more while trying to figure out the api endpoint.

@toy

This comment has been minimized.

Copy link
Contributor

toy commented Sep 24, 2014

@drbrain Resolv::DNS supports setting timeout only in ruby >= 2.0. Is it acceptable to use Timeout in this case?

@luislavena

This comment has been minimized.

Copy link
Member

luislavena commented Sep 26, 2014

@drbrain I can confirm that with RubyGems 2.2.0, installation speed increased considerably, also on Windows.

Take this as example:

https://ci.appveyor.com/project/luislavena/test-ruby-c-extension/build/7

Ruby 1.9.3 (RubyGems 1.8.28) and Ruby 2.0.0 (RubyGems 2.0.14) didn't present this slowdown.

AppVeyor runs on Azure, perhaps that could be the reason? I can spin up an Azure machine to test things out if needed.

Let me know how can I help to solve this issue.

Thank you.

@jamesmeador

This comment has been minimized.

Copy link

jamesmeador commented Jan 7, 2015

Is this still causing problems for anyone else? We're seeing this even with our own local RubyGems repos. Workaround suggestions?

toy added a commit to toy/rubygems that referenced this issue Jan 21, 2015

Warn if getting SRV record fails, part of rubygems#1017
Feedback in case of problems with DNS configuration which can cause long timeout
@chino

This comment has been minimized.

Copy link

chino commented Apr 29, 2015

This is also an issue if your using a proxy and don't have dns at all in an isolated network. When using a proxy the proxy handles any required dns resolutions for you.

danielsdeleo added a commit to chef/chef that referenced this issue May 20, 2015

Install bundler before upgrading rubygems
Appveyor builds are timing out attempting to fetch a SRV record from
DNS, rubygems/rubygems#1017

In the default ruby install on appveyor, we have a version of rubygems
that is old and doesn't have the bug, so doing gem install before
upgrading works around the timeout issue.

danielsdeleo added a commit to chef/chef that referenced this issue May 21, 2015

Install bundler before upgrading rubygems
Appveyor builds are timing out attempting to fetch a SRV record from
DNS, rubygems/rubygems#1017

In the default ruby install on appveyor, we have a version of rubygems
that is old and doesn't have the bug, so doing gem install before
upgrading works around the timeout issue.

djberg96 added a commit that referenced this issue Aug 26, 2015

Merge pull request #1023 from toy/warn_srv_getting_failure
Warn if getting SRV record fails, part of #1017
@kch

This comment has been minimized.

Copy link

kch commented Aug 27, 2015

seeing this with os x vm in vmware fusion 8.

@djberg96

This comment has been minimized.

Copy link
Contributor

djberg96 commented Nov 4, 2015

How is this looking with the release of 2.5.0 and its new resolver?

@drbrain drbrain modified the milestones: 2.5, 2.6 Nov 18, 2015

@drbrain drbrain removed this from the 2.5 milestone Nov 18, 2015

@geoff-codes

This comment has been minimized.

Copy link

geoff-codes commented Dec 26, 2015

I'm still running into this with ruby 2.3.0 ...

@msiemens

This comment has been minimized.

Copy link

msiemens commented Apr 4, 2016

Having this with ruby 2.3.0 on Windows 7 using msys2

@lynncyrin lynncyrin removed the accepted label Jun 9, 2016

@larsch

This comment has been minimized.

Copy link

larsch commented Jul 20, 2016

Same issue on Ruby 2.2.4 on Windows.

The problem for me was is really in Win32::Resolv which attemps to detect the configured DNS address. But it has the bad habit of returning DNS server from interfaces that have been configured previously, but that you are no longer connected to (e.g. Wifi, USB Ethernet Dongles, etc.). As a workaround, you can remove these from HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces in the registry.

I have filed https://bugs.ruby-lang.org/issues/12604 on the issue.

@ceefour

This comment has been minimized.

Copy link

ceefour commented Oct 9, 2016

$ gem install --verbose bundler
ERROR:  Could not find a valid gem 'bundler' (>= 0), here is why:
          Unable to download data from https://rubygems.org/ - SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (https://rubygems.org/specs.4.8.gz)
Getting SRV record failed: DNS result has no information for _rubygems._tcp.rubygems.org

:(

@rmoriz

This comment has been minimized.

Copy link

rmoriz commented Sep 22, 2017

@colby-swandale why was this issue closed? It's still an issue (inside VMware Fusion/macOS) :-(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment