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

93

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

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

  • 2
    Может быть, теперь это следует перенести на сервер?
  • 0
    Нет необходимости, это можно решить, просто изменив строку в файле конфигурации
Показать ещё 2 комментария
Теги:
sqlplus
webrick

12 ответов

147

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

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

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

:DoNotReverseLookup => nil,

с

:DoNotReverseLookup => true,

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

  • 2
    Спасибо, мой хороший человек, это исправило это для меня.
  • 21
    Работал! У меня были проблемы с медленным Webrick при подаче статического контента с другого компьютера в нашей локальной сети. Это решило это. Единственное отличие было в том, что config.rb был в: ~ / .rvm / rubies / ruby-1.9.2-p180 / lib / ruby / 1.9.1 / webrick / config.rb - потому что мы используем RVM.
Показать ещё 15 комментариев
37

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

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

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

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

  • 1
    Спасибо большое!! Это решило мою проблему на Ubuntu 11.04 / 11.10 / 12.04
  • 1
    Ну, этот ответ кажется мне незамеченным героем!
Показать ещё 4 комментария
24

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

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

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

~/.rvm/rubies/ruby-<version>/lib/ruby/<version>/webrick/config.rb
  • 1
    Спасибо! Прежде чем я нашел ваш ответ, я искал .rvm, не нашел webrick и изменил / usr / lib, но это не помогло. Это сработало.
  • 0
    Я не уверен, что изменение ядра Ruby - это хорошее направление.
Показать ещё 2 комментария
15

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

На Хереку: https://devcenter.heroku.com/articles/rails3#webserver Дел >

Веб-сайт: 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, который позволяет dyno управлять собственной очереди запросов и избегать блокировки длинных запросов.

  • 0
    Идеальное решение, не меняя коды или что-либо в системе.
  • 0
    Оказывается, Синатра автоматически использует thin вместо webrick, если он установлен. Все, что мне нужно было сделать, это gem install thin . См. Sinatrarb.com/intro.html. Рекомендуется также запустить gem install thin, которую Sinatra подберет, если она будет доступна. РЕДАКТИРОВАТЬ: резкое улучшение производительности. От 1,3 с до 0,05 с.
6

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

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

server = HTTPServer.new {:DoNotReverseLookup => true, ...}
  • 0
    спасибо за подсказку, проверял неверный файл конфигурации, +1
5

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

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

2

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

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

2

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

  • 0
    Отлично. Это лучше, чем редактировать какой-нибудь файл webrick, который нужно менять после каждого обновления.
  • 0
    В моем случае добавляемая запись (для гостя Linux, на котором работает webrick) будет IP-адресом хоста Windows.
1

Это старый вопрос и ответ, который помог мне решить проблему :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?

0

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

Socket.do_not_reverse_lookup = true

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

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

0

Это очень поздний ответ, но я потратил большую часть дня на отладку этой самой проблемы с 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
0

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

sudo iptables -F

Ещё вопросы

Сообщество Overcoder
Наверх
Меню