Вебрік дуже повільно реагує. Як це пришвидшити?

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

Здається, все це почалося після того, як я встановив базовий клієнт Oracle та SQLPLUS. Чи слід мені підозрювати Oracle? Хтось переживав щось подібне до цього?

Маючи ту саму проблему тут (навіть через рік). Під Linux ви повинні зробити наступне:

Знайдіть файл /usr/lib/ruby/1.9.1/webrick/config.rb та відредагуйте його.

Замініть рядок

:DoNotReverseLookup => nil,

з

:DoNotReverseLookup => true,

Перезапустіть webrick, і він буде працювати як шарм :)

Була та сама проблема. Для мене цей пост містив рішення. Якщо ви використовуєте Ubuntu, зупиніть (або видаліть) avahi-daemon. service avahi-daemon stopзупиняє демон.

Зараз Вебрик почувається дуже швидко.

Проблема має старий звіт у Rails Lighthouse , однак Ruby-on-Rails з того часу перенесли свої квитки у github ; На жаль, ця стара проблема зберігається досі.

Однак майте на увазі, що якщо ви насправді щось використовуєте avahi-daemon , наприклад, знаходите принтери та сканери у своїй мережі, це вже не працюватиме.

Просто була та сама проблема.

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

зробив фокус і для мене. Про всяк випадок, коли ти бігаєш рубіном під rvm, ось шлях:

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

"Тонкий" тепер є чудовим варіантом для запуску локально та на Героку:

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

У мене була неясна подібна проблема, яка виявилася при доступі до сервера WEBrick через VPN. Запити зайняли б багато часу, більшість із них, нічого не трапляючись на дроті. Оскільки ні Rubins1.9, mongrelні thinдорогоцінні камені не працювали з 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: Виправлена ​​помилка регресії в реалізації параметра конфігурації DoNotReverseLookup # 731

Рішенням, як зазначено в запиті, є зміна рядка 181 на lib/webrick/server.rbз цього:

sock.do_not_reverse_lookup = config[:DoNotReverseLookup]

До цього:

unless config[:DoNotReverseLookup].nil?

Поділіться тут, якщо хтось наткнеться на цю розглянуту нитку запитань / відповідей і зацікавлений у прогресі у вирішенні цієї проблеми в Ruby core. Будемо сподіватися, що цей витяг буде об’єднаний або основна проблема буде якось вирішена в наступному випуску Ruby; можливо 2.1.6?

Це дуже пізня відповідь, але я витратив значну частину дня, налагоджуючи саме цю проблему, 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

Немає DoNotReverseLookupопції у веб-цеглі ruby ​​1.8.x. Рішення полягає в тому, щоб:

Socket.do_not_reverse_lookup = true

десь на початку вашого сценарію.

Джерело: WEBrick and Socket.do_not_reverse_lookup: Повість у двох актах

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

sudo iptables -F