Issue #18573 has been updated by Josh Cooper. Status changed from Needs More Information to Accepted Target version set to 3.2.0
When running webrick, its `HTTPServer` calls `HTTPRequest#parse` on the accepted socket, and that results in a call to `IPSocket#peeraddr`. In ruby versions prior to 1.9.2p0, this <b>always</b> results in a reverse DNS lookup (as does calling `IPSocket#addr`). In ruby 1.9.0, the webrick [:DoNotReverseLookup](https://github.com/ruby/ruby/commit/0d8a0904d93e9600ccd095eabd5e4165c15987ff) option was added to allow users to disable reverse lookups. And [Rails](https://github.com/rails/rails/issues/4542) did. During development of ruby 1.9.2p0, the default value of `BasicSocket#do_not_reverse_lookup` was changed to `true` in [ruby-core:r9858](https://github.com/ruby/ruby/commit/85176676e5067117a8494ad207bbaf0796564bc3). At some point the default was accidentally changed back to false, and then was fixed again in [ruby-core:r26541](https://github.com/ruby/ruby/commit/4dfd71005cf4ee14db965cd155417f8657ed2c24) in time for ruby 1.9.2p0. As a result, when running 1.8.x-1.9.1, webrick-based puppetmasters will always perform reverse DNS lookups, for every request, and therefore, every catalog request, every pluginsync'ed file, etc. A second issue is that the puppetmaster calls `HTTPRequest#peeraddr` on every REST request, even though all we need is the peer IP address: <pre> if peer = request.peeraddr and ip = peer[3] result[:ip] = ip end </pre> This doesn't lead to additional reverse DNS lookups, because the `HTTPRequest` caches the parsed `@peeraddr` value, but it seems unnecessary. I think we should instead call `HTTPRequest#remote_ip`, which will never result in a reverse DNS lookup and it also handles [X-Forwarded-For](http://en.wikipedia.org/wiki/X-Forwarded-For) headers that identify the originating client IP, but that method is only in ruby 1.9.1p378 and up. ---------------------------------------- Refactor #18573: File downloads from pluginsync extremely slow https://projects.puppetlabs.com/issues/18573#change-89081 * Author: Brian Wong * Status: Accepted * Priority: Normal * Assignee: Brian Wong * Category: * Target version: 3.2.0 * Affected Puppet version: 3.0.1 * Keywords: DNS pluginsync * Branch: ---------------------------------------- The [standard library module](http://forge.puppetlabs.com/puppetlabs/stdlib) provides numerous parser functions. It is extremely slow on my client's first puppet agent invocation to download these files. I found that each file downloaded requires a DNS call to the puppet server. I am not sure if it is advantageous, or even possible, to download plugins from multiple sources and therefore believe there should only be one DNS call made regardless of how many files must be downloaded. It is extremely inefficient in the current model. The problem happens only when I am using my Vagrant VMs as Puppet clients though the problem is not limited to these systems. Other systems, notably those running in EC2 (VPC) do not experience the problem. This is because the DNS calls made in EC2 return much more quickly than my local virtual machine setup. My situation is quite similar to [this user experience](https://groups.google.com/forum/?fromgroups=#!topic/puppet-users/Ek4jSO7zC1E) but the solution does not apply to me as it is not the Puppet server performing DNS calls in my case. A `tcpdump` on both server and client during the pluginsync has proven this to me. I am running CentOS 6.3 on both client and server. The puppet version on both client and server is 3.0.1. Please refactor/redesign the DNS calls performed during the pluginsync operation to reduce unnecessary network calls. Thank you. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
