Webrick очень медленно реагирует. Как ускорить его?

Ответ 1

Имея ту же самую проблему здесь (даже год спустя). Под linux вы должны сделать следующее:

Найдите файл /usr/lib/ruby/ 1.9.1/webrick/config.rb и отредактируйте его.

Заменить строку

:DoNotReverseLookup => nil,

с

:DoNotReverseLookup => true,

Перезагрузите webrick, и он будет работать как шарм:)

Ответ 2

Была та же проблема. Для меня этот пост содержал решение. Если вы находитесь на Ubuntu, остановите (или удалите) avahi-daemon. service avahi-daemon stop останавливает демон.

Сегодня Webrick чувствует себя очень быстро.

У проблемы есть старый отчет в Rails Lighthouse, однако Ruby-on-Rails переместили их билеты в github с тех пор; К сожалению, эта старая проблема все еще сохраняется.

Помните, что если вы действительно используете avahi-daemon для чего-то, например нахождение принтеров и сканеров в вашей сети, это не будет работать больше.

Ответ 3

Просто такая же проблема.

...
:DoNotReverseLookup => true,
...

сделал трюк для меня тоже. На всякий случай, когда вы запускаете ruby ​​под rvm, вот путь, по которому нужно идти:

~/.rvm/rubies/ruby-<version>/lib/ruby/<version>/webrick/config.rb

Ответ 4

"Тонкий" теперь отличный вариант для запуска как локального , так и на Heroku:

gem "thin"

Ответ 5

У меня была смутно подобная проблема, которая проявилась при доступе к WEBrick-серверу через VPN. Запросы занимают много времени, большинство из них ничего не происходит на проводе. Поскольку ни один из mongrel и thin gems не работал с Ruby1.9 в Windows, и я никак не мог ввязываться в компиляцию из исходного кода, мне нужно было придерживаться WEBrick.

Исправление заключалось в установке параметра конфигурации DoNotReverseLookup на true при создании сервера WEBrick:

server = HTTPServer.new {:DoNotReverseLookup => true, ...}

Ответ 6

Вы можете использовать Apache или установить Thin. В вашем Gemfile: gem 'thin'

Или вы можете проверить список веб-серверов для рельсов.

Ответ 7

пытался сделать это с помощью webrick на 1.8.7 и не смог найти конфигурацию для изменения. Тем не менее, чит, который вы можете использовать, заключается в добавлении в файл hosts сервера, на котором выполняется webrick ip-адрес, который он пытается отменить поиск.

Ответ 8

Я часто испытывал 10 секунд задержки с Sinatra. Этот фрагмент решил для меня.

Добавьте это в начало вашего файла 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

Смотрите источник

Ответ 9

Это старый вопрос и ответ, который помог мне решить проблему :DoNotReverseLookup на локальной виртуальной машине разработки и хотел добавить дополнительную информацию. Эта веб-страница объясняет ошибку регрессии в ядре Ruby, что приводит к появлению этой проблемы для некоторых; акцент мой; длинный недостаток всего этого заключается в том, что есть запрос на получение GitHub для исправления ядра Ruby и, надеюсь, он будет одобрен и объединен в скором выпуске Ruby:

После нескольких часов устранения неполадок выяснилось, что это было! По-видимому, где-то вдоль эволюции Ruby standard lib от 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 всегда будет происходить для каждого нового подключения, потенциально вызывая серьезную задержку.

В связи с этим обнаружением запрос на удаление GitHub от автора, предлагающий как устранить проблему в исходном коде Ruby WEBrick: Исправить ошибку регрессии в версии WEBrick: DoNotReverseLookup версии # 731

Решение, описанное в запросе, состоит в том, чтобы изменить строку 181 в lib/webrick/server.rb следующим образом:

sock.do_not_reverse_lookup = config[:DoNotReverseLookup]

Для этого:

unless config[:DoNotReverseLookup].nil?

Разделяйте здесь, если кто-то спотыкается над этим хорошо рассмотренным вопросом/вопросом ответа и заинтересован в прогрессе в решении этой проблемы в ядре Ruby. Надеемся, что это притяжение будет объединено или основной вопрос будет рассмотрен каким-то образом в следующем выпуске Ruby; возможно, 2.1.6?

Ответ 10

В моей, вероятно, редкой ситуации, это сработало после того, как я сбросил мои iptables, у этого не было никаких побочных эффектов, потому что у меня не было никаких пользовательских правил (только по умолчанию Ubuntu разрешает все):

sudo iptables -F

Ответ 11

Это очень поздний ответ, но я потратил большую часть дня на отладку этой самой проблемы с Rails, запущенным на Vagrant. Изменение обратного DNS-поиска фактически не улучшало время запроса. Сочетание двух вещей потребовало загрузки моей страницы от ~ 20 секунд до ~ 3 секунд в режиме разработки:

Замените WEBrick на mongrel. Я должен был использовать предварительную версию или не устанавливать:

sudo gem install mongrel --pre

Затем добавьте его в мой Gemfile для dev:

group :test, :development do
  gem 'mongrel'
end

Начнул мой сервер так:

rails server mongrel -e development

Это сократилось на несколько секунд, 5 или 6 секунд, но все еще было ужасно медленным. Это была обледенение на торте - добавьте это также в Gemfile:

group :development do
  gem 'rails-dev-boost', :git => 'git://github.com/thedarkone/rails-dev-boost.git'
end

Ответ 12

В ruby ​​1.8.x webrick нет опции DoNotReverseLookup. Решение состоит в том, чтобы поставить:

Socket.do_not_reverse_lookup = true

где-то в начале вашего script.

Источник: WEBrick и Socket.do_not_reverse_lookup: Сказка в двух действиях