Webrick 的响应速度非常慢。如何加快？

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

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

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

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.

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

"Thin" is now a great option for running both locally and on Heroku:

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.

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

Also you can check the list of web-servers for 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

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

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

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

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?