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 будет запущен.

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

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

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

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

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

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

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

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

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

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

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

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

gem 'thin' 

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

bundle 

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

thin start