Webrick is very slow to respond. How to speed it up?

Question

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?

Answer 1

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 :)

Answer 2

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.

Answer 3

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

Answer 4

"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.

Answer 5

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, ...}

Answer 6

You can use Apache or install Thin. In your Gemfile : gem 'thin'

Or you can check the list of web-servers for rails.

Answer 7

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..

Answer 8

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

Answer 9

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?

Answer 10

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

Answer 11

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

Answer 12

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