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

Question

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

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

Answer 1

С той же проблемой здесь (даже через год). Под Linux вы должны сделать следующее:

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

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

:DoNotReverseLookup => nil,

с

:DoNotReverseLookup => true,

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

На Heroku: https://devcenter.heroku.com/articles/rails3#webserver

Веб-сайт: http://code.macournoyer.com/thin/

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

gem "thin"

... а затем запустите bundle и запустите свой сервер с thin start или rails s.

Обновление Heroku

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

С Синатрой я часто задерживался на 10 секунд. Этот фрагмент решил это для меня.

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

См. источник

Answer 8

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

Answer 9

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

Answer 10

В webby ruby ​​1.8.x нет опции DoNotReverseLookup. Решение поставить:

Socket.do_not_reverse_lookup = true

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

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