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

Question

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

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

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

89

ruby-on-rails oracle sqlplus webrick

Источник

21 июл '09 в 00:46

12 ответов

Другие вопросы по тегам ruby-on-rails oracle sqlplus webrick

user268273 12 авг '10 в 06:12 2010-08-12 06:12 · Answer 1 · 2010-08-12 06:12

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

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

Заменить линию

:DoNotReverseLookup => nil,

с

:DoNotReverseLookup => true,

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

140

Источник

user268273 12 авг '10 в 06:12

user193892 12 авг '11 в 09:25 2011-08-12 09:25 · Answer 2 · 2011-08-12 09:25

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

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

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

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

user603309 04 фев '11 в 14:41 2011-02-04 14:41 · Answer 3 · 2011-02-04 14:41

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

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

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

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

23

Источник

user603309 04 фев '11 в 14:41

user204044 07 июл '12 в 00:04 2012-07-07 00:04 · Answer 4 · 2012-07-07 00:04

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

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

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

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

gem "thin"

... а затем запустите bundle и запустите свой сервер с 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 управлять собственной очередью запросов и избегать блокировки на длинные запросы.

user25457 11 мар '10 в 11:32 2010-03-11 11:32 · Answer 5 · 2010-03-11 11:32

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

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

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

user1306271 29 сен '12 в 10:17 2012-09-29 10:17 · Answer 6 · 2012-09-29 10:17

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

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

5

Источник

user1306271 29 сен '12 в 10:17

user78336 03 июн '14 в 11:07 2014-06-03 11:07 · Answer 7 · 2014-06-03 11:07

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

Посмотреть источник

user435817 13 авг '11 в 02:03 2011-08-13 02:03 · Answer 8 · 2011-08-13 02:03

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

2

Источник

user435817 13 авг '11 в 02:03

user117259 13 дек '14 в 03:55 2014-12-13 03:55 · Answer 9 · 2014-12-13 03:55

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

user353802 27 июн '14 в 22:53 2014-06-27 22:53 · Answer 10 · 2014-06-27 22:53

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

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

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

user88597 12 дек '14 в 03:03 2014-12-12 03:03 · Answer 11 · 2014-12-12 03:03

Здесь нет DoNotReverseLookup опция в ruby 1.8.x вебрик. Решение состоит в том, чтобы поставить:

Socket.do_not_reverse_lookup = true

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

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

0

Источник

user88597 12 дек '14 в 03:03

user358906 25 фев '14 в 14:45 2014-02-25 14:45 · Answer 12 · 2014-02-25 14:45

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

sudo iptables -F

0

Источник

user358906 25 фев '14 в 14:45