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

У меня есть приложение Rails, которое я запускаю на своем сервере. Когда я перехожу на удаленный рабочий стол и пытаюсь загрузить приложение, серверу требуется 3-4 минуты, чтобы ответить простой HTML-страницей. Однако, когда я загружаю страницу локально на сервере, она появляется буквально через секунду. Я попытался проверить связь с сервером со своего удаленного рабочего стола, и проверка прошла успешно за разумное время.

Кажется, все это началось после того, как я установил базовый клиент Oracle и SQLPLUS. Стоит ли подозревать Oracle? Кто-нибудь испытывал что-нибудь подобное?

То же самое здесь (даже год спустя). В Linux вам необходимо сделать следующее:

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

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

:DoNotReverseLookup => nil,

с участием

:DoNotReverseLookup => true,

Перезапустите вебрик, и он заработает как шарм :)

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

Уэбрик теперь чувствует себя очень быстрым.

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

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

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

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

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

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

"Тонкий" теперь отличный вариант для работы как локально и на Heroku:

Сайт: http://code.macournoyer.com/thin/

Вы можете использовать его локально, поместив в свой Gemfile:

gem "thin"

... а затем запустите пакет и запустите свой сервер с помощью thin startили rails s.

Обновление на Heroku

Тонкий сейчас считается плохим выбором для Heroku. Больше информации здесь:

https://blog.heroku.com/archives/2013/4/3/routing_and_web_performance_on_heroku_a_faq

Их рекомендация:

Переключитесь на параллельный веб-сервер, такой как Unicorn или Puma на JRuby, что позволяет дино управлять своей собственной очередью запросов и избегать блокировки при длинных запросах.

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

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

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

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

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

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

Я часто сталкивался с 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

См. Источник

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

После нескольких часов устранения неполадок оказалось, что это так! По-видимому, где-то в процессе эволюции стандартной библиотеки Ruby с 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's: DoNotReverseLookup # 731

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

sock.do_not_reverse_lookup = config[:DoNotReverseLookup]

К этому:

unless config[:DoNotReverseLookup].nil?

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

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

Замени WEBrick на ублюдка. Мне пришлось использовать предварительную версию, иначе она не установилась:

sudo gem install mongrel --pre

Затем добавьте его в мой Gemfile для разработчиков:

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

В DoNotReverseLookupвебрике ruby ​​1.8.x опций нет. Решение - поставить:

Socket.do_not_reverse_lookup = true

где-то в начале вашего скрипта.

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

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

sudo iptables -F