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?

Ideogram

Maybe this should now be moved to serverfault? – Audra

There is no need, this can be solved by simply modifying a line in a configuration file – Donley

@AmigableClarkKant Webrick's more of a developer tool, so seems better to stay on SO. – Tryptophan

goodness, and all along I attributed the problem to vmware, burn in hell webrick :( – Plethora

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

Donley

Worked! I had problems with Webrick being slow when serving static content from another computer in our local network. This solved it. The only difference was that config.rb was in: ~/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/webrick/config.rb - because we are using RVM. – Dick

btw, I didn't have that key, so I just added it and it worked – Middlebrow

where did you add it? what section? – Spiky

It is supposed to be in the General section according to ruby-doc.org/stdlib/libdoc/webrick/rdoc/classes/WEBrick/…. – Totalizer

The version of ruby I have is ruby-1.8.7-p330 and it doesn't seem to have the DoNotReverseLookup option. The string "DoNotReverseLookup" does not appear in webrick's config.rb or anywhere in ~/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8. Is there any nice way to fix this problem in ruby-1.8.7-p330? – Totalizer

This is fantastic. I've been dealing with this on VirtualBox for months, now. Thanks! – Chardin

Another thanks! This should be in the Rails Guides as a "TIP" ! – Pruchno

It worked. I found the Webrick config file at /usr/local/lib/ruby/1.9.1/webrick/config.rb I was having a very slow connection to the rails server that is hosted in a VirtualBox ubuntu guest. I am accessing the web app from the host OS using port forwarding. – Quant

Just in case you won't scroll the few lines below this answer, here you go for RVM: ~/.rvm/rubies/ruby-<version>/lib/ruby/<version>/webrick/config.rb – Spinel

w◉◡◉t! ttttttttttyyyyyyyyyy <3 – Scallop

This fix didn't work for me, it turns out that VirtualBox shared folders via vboxfs are also an issue: #15295798 – Lathery

Thanks! On Windows boxes that uses RubyInstaller, config.rb can be found at C:\Ruby193\lib\ruby\1.9.1\webrick – Literally

@FloydPink that actually should be C:\RailsInstaller\Ruby1.9.3\lib\ruby\1.9.1\webrick on Windows with rails set up using RailsInstaller. – Elative

Did not solve my problem. Prof. Falken's answer below did. – Counterproposal

@DavidGrayson for 1.8.x ruby, see my answer below using: Socket.do_not_reverse_lookup – Kobarid

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.

Audra

Thanks very much!! It solved my problem on Ubuntu 11.04/11.10/12.04 – Tagmemics

Well this answer seems to be the unsung hero for me! – Lefkowitz

This did it for me, too. Running an OLD (1.8.7) app on Ubuntu 13.04 – Pantelegraph

this solution actually puts me into trouble as by stopping this causes network services to go nuts! check the following url forums.fedoraforum.org/showthread.php?t=124837 – Suggestibility

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

Spinel

Thanks! Before I found your answer, I searched .rvm and didn't find webrick, and changed the /usr/lib one and that didn't help. This worked. – Puzzlement

@KenBarber Pretty sure it's not a good direction, but in order to have a nice and small development-cycle it's okay to do just this modification to your local RVM installation. And by the way, it's just your users profile, you won't bother anyone else... – Spinel

@Spinel perhaps you are right, but it doesn't persist through upgrades, nor is it a solution you can easily pass around to your fellow devs. Perhaps a monkey patch on Rails in this case is better shrug. Anyway its fixed now: github.com/rails/rails/commit/… ... – Glow

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.

Gorrian

A perfect solution by not changing codes or anything in system. – Interchange

Turns out Sinatra uses thin instead of webrick automatically if it is installed. All I had to do is gem install thin. See sinatrarb.com/intro.html It is recommended to also run gem install thin, which Sinatra will pick up if available. EDIT: Drastic performance improvements. From 1.3s to 0.05s. – Tallow

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

Rhapsody

Answer 6

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

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

Hickman

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

Tycoon

Great. This is better then editing some webrick file which needs change after each update. – Tideway

In my case the entry to be added (for the Linux guest running webrick) would be the ip address of the Windows host – Plethora

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

Circinus

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?

Extrusive

Answer 10

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

Kleper

Answer 11

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

Cosmetician

Answer 12

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

Kobarid