Tente executar
sudo service avahi-daemon stop
Tente também configurar o WEBrick /usr/lib/ruby//webrick/config.rb
:DoNotReverseLookup => true
Veja também: "Stackoverflow WEBrick lento da área de trabalho remota"
Estou usando o Ubuntu (Lucid Lynx) para aprender Ruby On Rails. Estou executando o Ubuntu no VirtualBox (o host é o Windows 7 Ultimate), usando redes em ponte.
Quando executo meu aplicativo Rails e aponto o navegador para ele usando localhost: 3000, o aplicativo responde imediatamente e minha página é renderizada em um segundo ou dois.
No entanto, se eu usar 10.0.0.5:3000 (onde 10.0.0.5 é meu endereço IP relatado usando ifconfig ), a resposta do meu aplicativo rails é incrivelmente lenta - talvez 30 segundos ou mais para o servidor responder e renderizar a página.
Isso acontece no Firefox e no Chrome. Além disso, quando eu bato no aplicativo Rails do host (para testá-lo no IE), recebo a mesma resposta slooooooow.
Alguma idéia do que pode estar acontecendo? Eu tentei com dois roteadores diferentes e em duas redes diferentes (trabalho e casa) com o mesmo resultado.
Elogios a todos.
Tente executar
sudo service avahi-daemon stop
Tente também configurar o WEBrick /usr/lib/ruby//webrick/config.rb
:DoNotReverseLookup => true
Veja também: "Stackoverflow WEBrick lento da área de trabalho remota"
É um problema da WEBrick, sem problemas quando você usa outros servidores da Web.
Eu experimentei o Mongrel and Thin com o Ruby on Rails 3.0.x, ambos funcionando muito bem.
Sugiro usar o Mongrel - basta adicioná-lo ao seu Gemfile:
gem "mongrel"
ou você pode configurá-lo apenas para desenvolvimento e teste, não para interromper a produção:
group :test, :development do
gem "mongrel"
end
Agora inicie o servidor da mesma forma que você fez antes e o Mongrel é iniciado em vez do WEBrick.
Se você preferir o Thin, você precisa iniciar o servidor com thin start ou o WEBrick será iniciado.
Eu tive este mesmo problema no VirtualBox e no VMware. Não tenho certeza qual é o problema ... ele age como se o servidor Rails estivesse procurando algo que tivesse que ser expirado? O servidor Rails reporta tempos de renderização rápidos no log, mas demora uma eternidade para responder a cada solicitação. Acontece tanto no Rails 2.3.8 como no Rails 3.0.3 para mim em uma instância do Ubuntu em particular (testada no VirtualBox e no VMware). Eu tive outro Ubuntu VM em outra caixa que não tem o problema ...
Depois de perseguir isso frustrantemente há algum tempo, minha solução é usar o Phusion Passenger no modo de desenvolvimento e o Apache.
Atenção: esta é uma não-resposta (além da sugestão de usar o Passenger), mas estou documentando minha própria experiência, bem como algumas experiências que fiz que, esperamos, nos ajudaram a chegar mais perto de uma conclusão.
Eu tenho exatamente o mesmo problema. Surgiu de repente. Eu também tenho uma observação semelhante a você na frente do ping. Meu convidado Ubuntu também executa uma pilha LAMP regular, e não há absolutamente nenhum problema de serviço lá. Por que vale a pena, parece que unix_stream_data_wait é (na maioria das vezes?) Culpado pelo hangup. Eu não posso realmente analisar o que isso significa além do trivial ou como investigar mais.
Isso parece ser independente do número da porta (mover os trilhos para uma porta mais baixa, como em rails s -p 30 , não altera o problema, e outros serviços configurados para escutar a porta 3000 não encontram os mesmos problemas de serviço). / p>
Ele também parece ser independente do código do aplicativo. Eu tentei com um aplicativo bare rails, e o atraso reapareceu.
O atraso também parece variar em duração, levantando um problema potencial com a hipótese de que o Rails está expirando de maneira previsível.
As solicitações enviadas no mesmo "lote" parecem ser atendidas ao mesmo tempo. Isso sugere que há algo na interface entre o processo Rails e o manipulador de rede, onde a interface é apenas lenta, mas limpa sua placa quando a transação eventualmente passa.
No geral, estranhamente esquisita.
Eu apenas fui com passageiro em seu lugar.
Este é realmente estranho. Descobri que, se eu começar o servidor rails de respostas putty são muito mais rápidos, do que se eu iniciá-lo a partir da janela do VirtualBox ...
Se você estiver usando o WEBrick, você pode tentar usar o Thin. Adicione thin ao seu Gemfile:
gem 'thin'
e instale-o executando:
bundle
Inicie o servidor executando:
thin start
Tags networking virtualbox rails ubuntu