Ruby-on-rails Webrick 反应很慢。如何加快速度？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1156759/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Webrick is very slow to respond. How to speed it up?
提问by Mosty Mostacho
I have a Rails application that I'm running on my server. When I go to a remote desktop and attempt to load the application, the server takes a good 3-4 minutes to respond with a simple HTML page. However, when I load up the page locally on the server, the page shows up in just a second. I tried pinging the server from my remote desktop and the pings are going through successful in a reasonable amount of time.
我有一个在我的服务器上运行的 Rails 应用程序。当我转到远程桌面并尝试加载应用程序时，服务器需要 3-4 分钟才能响应一个简单的 HTML 页面。但是，当我在服务器上本地加载页面时，页面会在一秒钟内显示出来。我尝试从我的远程桌面 ping 服务器，并且 ping 在合理的时间内成功完成。
This all seems to have started after I installed Oracle's basic client and SQLPLUS. Should I suspect Oracle? Has anyone experienced anything similar to this?
这一切似乎都是在我安装了 Oracle 的基本客户端和 SQLPLUS 之后开始的。我应该怀疑甲骨文吗？有没有人经历过类似的事情？
回答by Mosty Mostacho
Having the same issue here (even a year later). Under linux you have to do the following:
在这里（即使是一年后）也有同样的问题。在 linux 下，您必须执行以下操作：
Look for the file /usr/lib/ruby/1.9.1/webrick/config.rb and edit it.
查找文件 /usr/lib/ruby/1.9.1/webrick/config.rb 并编辑它。
Replace the line
更换线路
:DoNotReverseLookup => nil,
with
和
:DoNotReverseLookup => true,
Restart webrick and it'll work like a charm :)
重新启动 webrick，它会像魅力一样工作:)
回答by Prof. Falken contract breached
Had the same problem. For me, this postheld the solution. If you are on Ubuntu, stop (or uninstall) the avahi-daemon. service avahi-daemon stopstops the daemon.
有同样的问题。对我来说，这篇文章包含了解决方案。如果您使用的是 Ubuntu，请停止（或卸载）avahi-daemon. service avahi-daemon stop停止守护进程。
Webrick now feels veryspeedy.
Webrick 现在感觉非常快。
The problem has an old report in Rails Lighthouse, however, Ruby-on-Rails have moved their tickets to githubsince then; Kind of unfortunate that this old problem persists still.
该问题在 Rails Lighthouse 中有一个旧报告，但是，Ruby-on-Rails从那时起已将其票证移至 github；有点不幸的是，这个老问题仍然存在。
Be aware though, that if you actually useavahi-daemonfor something, like finding printers and scannerson your network, that won't work anymore.
但请注意，如果您真的使用avahi-daemon某些东西，例如在您的网络上查找打印机和扫描仪，那将不再起作用。
回答by Kjellski
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 下运行 ruby，这里是要走的路：
~/.rvm/rubies/ruby-<version>/lib/ruby/<version>/webrick/config.rb
回答by Jamon Holmgren
"Thin" is now a great option for running both locally and on Heroku:
“瘦”现在是在本地运行的绝佳选择 在 Heroku 上：
Website: http://code.macournoyer.com/thin/
网站：http: //code.macournoyer.com/thin/
You can use it locally by putting in your Gemfile:
您可以通过放入 Gemfile 在本地使用它：
gem "thin"
... and then run bundle and start your server with thin startor rails s.
...然后运行 bundle 并使用thin start或启动您的服务器rails s。
Update on Heroku
Heroku 更新
Thin is now considered a badchoice for Heroku. More information here:
Thin 现在被认为是Heroku 的一个糟糕选择。更多信息在这里：
https://blog.heroku.com/archives/2013/4/3/routing_and_web_performance_on_heroku_a_faq
https://blog.heroku.com/archives/2013/4/3/routing_and_web_performance_on_heroku_a_faq
Their recommendation:
他们的建议：
Switch to a concurrent web backend like Unicorn or Puma on JRuby, which allows the dyno to manage its own request queue and avoid blocking on long requests.
切换到 JRuby 上的 Unicorn 或 Puma 等并发 Web 后端，这允许 dyno 管理自己的请求队列并避免阻塞长请求。
回答by mackenir
I had a vaguely similar problem that manifested itself when accessing a WEBrick server via a VPN. Requests would take a long time, most of it with nothing happening on the wire.
Since neither mongrelnor thingems worked with Ruby1.9 on Windows and there was no way I was getting myself embroiled in compiling stuff from source, I needed to stick with WEBrick.
在通过 VPN 访问 WEBrick 服务器时，我遇到了一个模糊的类似问题。请求需要很长时间，其中大部分时间都没有在线上发生。由于Ruby1.9mongrel和thingems都不能在 Windows 上运行，而且我无法让自己卷入从源代码编译的过程中，因此我需要坚持使用 WEBrick。
The fix was to set the config parameter DoNotReverseLookupto true, when creating the WEBrick server:
整个解决方案的配置参数设置DoNotReverseLookup到true，创建WEBrick服务器时：
server = HTTPServer.new {:DoNotReverseLookup => true, ...}
回答by Matz Heri
You can use Apacheor install Thin. In your Gemfile : gem 'thin'
您可以使用Apache或安装Thin. 在您的 Gemfile 中：gem 'thin'
Also you can check the list of web-servers for rails.
回答by patrickdavey
Was trying to do this with webrick on 1.8.7 and couldn't find the config to change. However, a cheat you can use is to add to the hosts file of the server which is running webrick the ip address it is trying to reverse lookup..
试图在 1.8.7 上使用 webrick 执行此操作，但找不到要更改的配置。但是，您可以使用的作弊方法是将它试图反向查找的 IP 地址添加到运行 webrick 的服务器的主机文件中。
回答by neoneye
I experienced 10 seconds delays frequently with Sinatra. This snippet solved it for me.
我在使用 Sinatra 时经常遇到 10 秒的延迟。这个片段为我解决了它。
Add this near the top of your app.rbfile
将此添加到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
See source
查看来源
回答by JakeGould
This is an old question and answer thread that helped me solve the :DoNotReverseLookupissue on a local development virtual machine and wanted to add additional info. This web page explains the regression errorin Ruby core that lead to this issue appearing for some; emphasis is mine; the long an short of all of this is there is a GitHub pull request for a Ruby core fix to this and hopefully it will be approved and merged in a soon-ish release of Ruby:
这是一个旧的问答线程，它帮助我解决:DoNotReverseLookup了本地开发虚拟机上的问题，并希望添加其他信息。此网页解释了Ruby 核心中导致此问题出现的回归错误；重点是我的；总而言之，GitHub 上有一个针对 Ruby 核心修复程序的 pull request，希望它能在即将发布的 Ruby 版本中获得批准和合并：
After a few hours of troubleshooting, it turned out that it was! Apparently, somewhere along the evolution of Ruby's standard lib from 1.8.6 to 2.0.0, WEBrick acquired a new configuration option
:DoNotReverseLookupthat is set tonilby default. Then, deep in the guts of WEBrick's request processing code, it sets thedo_not_reverse_lookupflag on the incoming connection socket instance to the value ofconfig[:DoNotReverseLookup]. Since this value isnil, which is falsy, the effect is the same as setting it tofalse, overriding the globalSocket.do_not_reverse_lookupflag. So, unless you have :DoNotReverseLookup => truein your WEBrick config, reverse DNS lookup will always happen for each new connection, potentially causing serious latency.
经过几个小时的故障排除，原来是这样！显然，在 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 查找将始终针对每个新连接进行，这可能会导致严重的延迟。
Related to this discovery is a GitHub pull request from the authorproposing how to repair the issue in the Ruby WEBrick source code: Fix regression bug in WEBrick's :DoNotReverseLookup config option implementation #731
与此发现相关的是作者的 GitHub 拉取请求，提出如何修复 Ruby WEBrick 源代码中的问题：修复 WEBrick 的 :DoNotReverseLookup 配置选项实现中的回归错误 #731
The solution as outlined in the request is to change line 181 in lib/webrick/server.rbfrom this:
请求中概述的解决方案是将第 181 行更改lib/webrick/server.rb为：
sock.do_not_reverse_lookup = config[:DoNotReverseLookup]
To this:
对此：
unless config[:DoNotReverseLookup].nil?
Sharing here if anyone stumbles over this well regarded question/answer thread and are interested in the progress in solving this issue in Ruby core. Hopefully this pull will be merged or the underlying issue be dealt with in some way in the next release of Ruby; maybe 2.1.6?
如果有人偶然发现了这个备受推崇的问题/答案线程并对在 Ruby 核心中解决此问题的进展感兴趣，请在此处分享。希望这个 pull 会被合并，或者在下一个 Ruby 版本中以某种方式处理潜在的问题；也许2.1.6？
回答by AlienWebguy
This is a very late answer but I spent a good part of the day debugging this very issue with Rails running on Vagrant. Changing the reverse DNS lookup didn't actually improve request times at all. A combination of two things took my page load from ~20 seconds to ~3 seconds in development mode:
这是一个很晚的答案，但我花了一天的大部分时间用在 Vagrant 上运行的 Rails 来调试这个问题。更改反向 DNS 查找实际上根本没有改善请求时间。在开发模式下，两件事的结合使我的页面加载时间从约 20 秒减少到约 3 秒：
Replace WEBrick with mongrel. I had to use the prerelease version or it wouldn't install:
用杂种替换 WEBrick。我必须使用预发布版本，否则它不会安装：
sudo gem install mongrel --pre
Then add it to my Gemfile for dev:
然后将它添加到我的 Gemfile for dev 中：
group :test, :development do
gem 'mongrel'
end
Started my server like this then:
然后像这样启动我的服务器：
rails server mongrel -e development
That cut a few seconds off, 5 or 6 seconds, but it was still terribly slow. This was the icing on the cake- add this as well to the Gemfile:
这减少了几秒钟，5 或 6 秒，但它仍然非常慢。这是锦上添花- 将其添加到 Gemfile 中：
group :development do
gem 'rails-dev-boost', :git => 'git://github.com/thedarkone/rails-dev-boost.git'
end
