Ubuntu в Virtualbox - веб-сервер WEBrick работает очень медленно при использовании локального IP-адреса

Попробуйте запустить

sudo service avahi-daemon stop

Также попробуйте установить WEBrick /usr/lib/ruby//webrick/config.rb

:DoNotReverseLookup => true

Также см.: "Stackoverflow WEBrick медленно с удаленного рабочего стола"

Это проблема WEBrick, никаких проблем при использовании других веб-серверов.

Я попробовал Mongrel и Thin с Ruby on Rails 3.0.x, оба отлично работали.

Я предлагаю использовать Mongrel - просто добавьте его в свой Gemfile:

gem "mongrel"

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

group :test, :development do
  gem "mongrel"
end

Теперь запустите сервер так же, как вы делали это раньше, и Mongrel запускается вместо WEBrick.

Если вы предпочитаете Thin, вам нужно запустить сервер с thin start или WEBrick будет запущен.

Если вы используете WEBrick, вы можете попробовать использовать Thin. Добавьте тонкий в ваш Gemfile:

gem 'thin'

и установите его, запустив:

bundle

Запустите сервер, запустив:

thin start

У меня такая же проблема возникала как в VirtualBox, так и в VMware. Не уверен, в чем проблема... он действует так, как будто сервер Rails ищет что-то, что нужно отключить по тайм-ауту? Сервер Rails сообщает о быстром времени рендеринга в журнале, но реагирует на каждый запрос вечно. Происходит для меня как в Rails 2.3.8, так и в Rails 3.0.3 на одном конкретном экземпляре Ubuntu (пробовал как в VirtualBox, так и в VMware). У меня была другая Ubuntu VM на другом компьютере, у которого не было проблем...

После разочаровывающей погони за этим в течение некоторого времени я решил использовать Phusion Passenger в режиме разработки и Apache.

Этот действительно странный. Я обнаружил, что если я запускаю сервер rails из замазки, ответы гораздо быстрее, чем если бы я запускал его из окна VirtualBox...

Предупреждение: это не ответ (кроме предложения просто использовать Passenger), но я документирую свой собственный опыт, а также некоторые эксперименты, которые я провел, которые, надеюсь, помогут нам приблизиться к выводу.

У меня точно такая же проблема. Это произошло внезапно. У меня также есть подобное наблюдение с вами на фронте пинга. Мой гость Ubuntu также запускает обычный стек LAMP, и там нет абсолютно никаких проблем с обслуживанием. Для чего это стоит, кажется, unix_stream_data_wait это (в основном?) виноват в зависании. Я не могу разобрать, что это значит за тривиальным или как исследовать дальше.

Кажется, это не зависит от номера порта (перемещение рельсов на более низкий порт, как в rails s -p 30 не меняет проблему, и другие службы, настроенные на прослушивание порта 3000, не сталкиваются с такими же проблемами службы).

Это также, кажется, не зависит от кода приложения. Я попробовал это с голым приложением рельсов, и задержка появилась снова.

Задержка также, кажется, изменяется по продолжительности, что порождает потенциальную проблему с гипотезой, что Rails предсказуемо истекает.

Запросы, отправленные в одной и той же "партии", по-видимому, выполняются в одно и то же время. Это говорит о том, что что-то есть в интерфейсе между процессом Rails и сетевым обработчиком, где интерфейс просто чертовски медленен, но очищает его тарелку, когда транзакция в конце концов проходит.

В общем, странно, странно, странно.

Я просто пошел с пассажиром вместо.