Webrick is very slow to respond. How to speed it up?
Ruby on-RailsOracleSqlplusWebrickRuby on-Rails Problem Overview
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.
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?
Ruby on-Rails Solutions
Solution 1 - Ruby on-Rails
Having the same issue here (even a year later). Under linux you have to do the following:
Look for the file /usr/lib/ruby/1.9.1/webrick/config.rb and edit it.
Replace the line
:DoNotReverseLookup => nil,
with
:DoNotReverseLookup => true,
Restart webrick and it'll work like a charm :)
Solution 2 - Ruby on-Rails
Had the same problem. For me, this post held the solution. If you are on Ubuntu, stop (or uninstall) the avahi-daemon
. service avahi-daemon stop
stops the daemon.
Webrick now feels very speedy.
The problem has an old report in Rails Lighthouse, however, Ruby-on-Rails have moved their tickets to github since then; Kind of unfortunate that this old problem persists still.
Be aware though, that if you actually use avahi-daemon
for something, like finding printers and scanners on your network, that won’t work anymore.
Solution 3 - Ruby on-Rails
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
Solution 4 - Ruby on-Rails
"Thin" is now a great option for running both locally and on Heroku:
On Heroku:
https://devcenter.heroku.com/articles/rails3#webserver
Website: http://code.macournoyer.com/thin/
You can use it locally by putting in your Gemfile:
gem "thin"
... and then run bundle and start your server with thin start
or rails s
.
Update on Heroku
Thin is now considered a bad choice for Heroku. More information here:
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.
Solution 5 - Ruby on-Rails
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 mongrel
nor thin
gems 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.
The fix was to set the config parameter DoNotReverseLookup
to true
, when creating the WEBrick server:
server = HTTPServer.new {:DoNotReverseLookup => true, ...}
Solution 6 - Ruby on-Rails
You can use Apache
or install Thin
. In your Gemfile : gem 'thin'
Also you can check the list of web-servers for rails.
Solution 7 - Ruby on-Rails
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..
Solution 8 - Ruby on-Rails
I experienced 10 seconds delays frequently with Sinatra. This snippet solved it for me.
Add this near the top of your app.rb
file
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
Solution 9 - Ruby on-Rails
This is an old question and answer thread that helped me solve the :DoNotReverseLookup
issue on a local development virtual machine and wanted to add additional info. This web page explains the regression error in 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:
> 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 :DoNotReverseLookup
that is set to nil
by default. Then, deep in the
> guts of WEBrick's request processing code, it sets the
> do_not_reverse_lookup
flag on the incoming connection socket instance
> to the value of config[:DoNotReverseLookup]
. Since this value is nil
,
> which is falsy, the effect is the same as setting it to false
,
> overriding the global Socket.do_not_reverse_lookup
flag. So, unless
> you have :DoNotReverseLookup => true
in your WEBrick config, reverse
> DNS lookup will always happen for each new connection, potentially
> causing serious latency.
Related to this discovery is a GitHub pull request from the author proposing how to repair the issue in the Ruby WEBrick source code: Fix regression bug in WEBrick's :DoNotReverseLookup config option implementation #731
The solution as outlined in the request is to change line 181 in lib/webrick/server.rb
from this:
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?
Solution 10 - Ruby on-Rails
In my probably rare situation, it worked after I flushed my iptables, this didn't have any side effects because I didn't have any custom rules (just the default Ubuntu allow all):
sudo iptables -F
Solution 11 - Ruby on-Rails
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:
Replace WEBrick with mongrel. I had to use the prerelease version or it wouldn't install:
sudo gem install mongrel --pre
Then add it to my 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:
group :development do
gem 'rails-dev-boost', :git => 'git://github.com/thedarkone/rails-dev-boost.git'
end
Solution 12 - Ruby on-Rails
There is no DoNotReverseLookup
option in ruby 1.8.x webrick. The solution is to put:
Socket.do_not_reverse_lookup = true
somewhere at the beginning of your script.
Source: WEBrick and Socket.do_not_reverse_lookup: A Tale in Two Acts