88

我有一个在我的服务器上运行的 Rails 应用程序。当我转到远程桌面并尝试加载应用程序时，服务器需要 3-4 分钟才能响应一个简单的 HTML 页面。但是，当我在服务器上本地加载页面时，页面会在一秒钟内显示出来。我尝试从远程桌面 ping 服务器，并且 ping 在合理的时间内成功完成。

这一切似乎都是在我安装了 Oracle 的基本客户端和 SQLPLUS 之后开始的。我应该怀疑甲骨文吗？有没有人经历过类似的事情？

4

12 回答 12

139

这里有同样的问题（甚至一年后）。在 linux 下，您必须执行以下操作：

查找文件 /usr/lib/ruby/1.9.1/webrick/config.rb 并编辑它。

换行

:DoNotReverseLookup => nil,

和

:DoNotReverseLookup => true,

重新启动 webrick，它会像魅力一样工作:)

于 2010-08-12T06:12:02.960 回答
36

有同样的问题。对我来说，这篇文章提供了解决方案。如果您在 Ubuntu 上，请停止（或卸载）avahi-daemon. service avahi-daemon stop停止守护进程。

Webrick 现在感觉很快。

这个问题在 Rails Lighthouse 中有一个旧报告，但是，Ruby-on-Rails 从那时起已经将他们的票移到了 github；不幸的是，这个老问题仍然存在。

但请注意，如果您实际使用 avahi-daemon某些东西，例如在网络上查找打印机和扫描仪，那将不再适用。

于 2011-08-12T09:25:04.380 回答
23

Just had the same problem. The

...
:DoNotReverseLookup => true,
...

did the trick for me too. Just in case you´re running ruby under the rvm, here is the path to go for:

~/.rvm/rubies/ruby-<version>/lib/ruby/<version>/webrick/config.rb
于 2011-02-04T14:41:23.133 回答
15

“瘦”现在是在本地运行的绝佳选择在 Heroku 上：

在 Heroku 上：https://devcenter.heroku.com/articles/rails3#webserver

网站： http ://code.macournoyer.com/thin/

您可以通过放入 Gemfile 来在本地使用它：

gem "thin"

...然后运行 ​​bundle 并使用thin startor启动您的服务器rails s。

Heroku 更新

Thin 现在被认为是 Heroku 的错误选择。更多信息在这里：

https://blog.heroku.com/archives/2013/4/3/routing_and_web_performance_on_heroku_a_faq

他们的建议：

切换到 JRuby 上的 Unicorn 或 Puma 等并发 Web 后端，这允许 dyno 管理自己的请求队列并避免阻塞长请求。

于 2012-07-07T00:04:48.740 回答
6

当通过 VPN 访问 WEBrick 服务器时，我遇到了一个类似的问题。请求会花费很长时间，其中大部分都没有在线上发生任何事情。由于无论是 gemsmongrel还是thingems 在 Windows 上都不能与 Ruby1.9 一起工作，而且我无法让自己卷入从源代码编译的东西，所以我需要坚持使用 WEBrick。

修复是在创建 WEBrick 服务器时将 config 参数设置DoNotReverseLookup为true：

server = HTTPServer.new {:DoNotReverseLookup => true, ...}
于 2010-03-11T11:32:44.047 回答
5

您可以使用Apache或安装Thin. 在您的 Gemfile 中：gem 'thin'

您还可以查看rails 的网络服务器列表。

于 2012-09-29T10:17:12.537 回答
2

试图在 1.8.7 上使用 webrick 执行此操作，但找不到要更改的配置。但是，您可以使用的一个作弊方法是将它试图反向查找的 IP 地址添加到运行 webrick 的服务器的主机文件中。

于 2011-08-13T02:03:51.140 回答
2

我在使用 Sinatra 时经常遇到 10 秒的延迟。这个片段为我解决了这个问题。

app.rb在文件顶部附近添加

class Rack::Handler::WEBrick
    class << self
        alias_method :run_original, :run
    end
    def self.run(app, options={})
        options[:DoNotReverseLookup] = true
        run_original(app, options)
    end
end

见源

于 2014-06-03T11:07:45.043 回答
1

这是一个旧的问答线程，它帮助我解决:DoNotReverseLookup了本地开发虚拟机上的问题，并希望添加更多信息。该网页解释了导致此问题出现的 Ruby 核心中的回归错误；重点是我的；所有这一切的长短是有一个 GitHub 拉取请求，要求对此进行 Ruby 核心修复，希望它会被批准并合并到即将发布的 Ruby 版本中：

经过几个小时的故障排除，原来是这样！显然，在 Ruby 标准库从 1.8.6 到 2.0.0 的演变过程中，WEBrick 获得了一个默认:DoNotReverseLookup设置为的新配置选项。nil然后，在 WEBrick 请求处理代码的深处，它将 do_not_reverse_lookup传入连接套接字实例上的标志设置为config[:DoNotReverseLookup]. 由于此值为nil，这是虚假的，因此效果与将其设置为 相同false，覆盖全局Socket.do_not_reverse_lookup标志。因此，除非您有 :DoNotReverseLookup => true在您的 WEBrick 配置中，否则每次新连接都会发生反向 DNS 查找，这可能会导致严重的延迟。

与此发现相关的是作者的 GitHub 拉取请求，该请求提出了如何修复 Ruby WEBrick 源代码中的问题：Fix regression bug in WEBrick's :DoNotReverseLookup config option implementation #731

请求中概述的解决方案是将第 181 行更改lib/webrick/server.rb为：

sock.do_not_reverse_lookup = config[:DoNotReverseLookup]

对此：

unless config[:DoNotReverseLookup].nil?

如果有人偶然发现这个备受推崇的问题/答案线程并且对在 Ruby 核心中解决此问题的进展感兴趣，请在此处分享。希望这个 pull 将被合并或在 Ruby 的下一个版本中以某种方式处理潜在的问题；也许是 2.1.6？

于 2014-12-13T03:55:22.303 回答
0

这是一个很晚的答案，但是我花了一天的大部分时间来调试在 Vagrant 上运行的 Rails 的这个问题。更改反向 DNS 查找实际上并没有改善请求时间。在开发模式下，两件事的结合使我的页面加载时间从约 20 秒到约 3 秒：

将 WEBrick 替换为 mongrel。我必须使用预发布版本，否则无法安装：

sudo gem install mongrel --pre

然后将其添加到我的 Gemfile for dev 中：

group :test, :development do
  gem 'mongrel'
end

然后像这样启动我的服务器：

rails server mongrel -e development

这减少了几秒钟，5或6秒，但它仍然非常慢。这是锦上添花- 将其添加到 Gemfile 中：

group :development do
  gem 'rails-dev-boost', :git => 'git://github.com/thedarkone/rails-dev-boost.git'
end
于 2014-06-27T22:53:20.067 回答
0

ruby 1.8.x webrick中没有DoNotReverseLookup选项。解决方案是：

Socket.do_not_reverse_lookup = true

在脚本开头的某个地方。

资料来源：WEBrick 和 Socket.do_not_reverse_lookup：两幕故事

于 2014-12-12T03:03:32.747 回答
0

在我可能很少见的情况下，它在我刷新 iptables 后起作用，这没有任何副作用，因为我没有任何自定义规则（只是默认的 Ubuntu 允许所有）：

sudo iptables -F
于 2014-02-25T14:45:40.100 回答