Webrick é muito lento para responder. Como acelerar?

Eu tenho um aplicativo Rails que estou executando no meu servidor. Quando vou para uma área de trabalho remota e tento carregar o aplicativo, o servidor leva cerca de 3-4 minutos para responder com uma página HTML simples. No entanto, quando eu carrego a página localmente no servidor, a página aparece em apenas um segundo. Tentei fazer o ping do servidor de minha área de trabalho remota e os pings estão funcionando com êxito em um período de tempo razoável.

Tudo parece ter começado depois que instalei o cliente básico da Oracle e o SQLPLUS. Devo suspeitar da Oracle? Alguém experimentou algo semelhante a isso?

Tendo o mesmo problema aqui (mesmo um ano depois). No Linux, você deve fazer o seguinte:

Procure o arquivo /usr/lib/ruby/1.9.1/webrick/config.rb e edite-o.

Substitua a linha

:DoNotReverseLookup => nil,

com

:DoNotReverseLookup => true,

Reinicie o webrick e funcionará perfeitamente :)

Tive o mesmo problema. Para mim, este post foi a solução. Se você estiver no Ubuntu, pare (ou desinstale) o avahi-daemon. service avahi-daemon stoppára o daemon.

Webrick agora parece muito rápido.

O problema tem um relatório antigo no Rails Lighthouse , entretanto, Ruby-on-Rails mudou seus tickets para o github desde então; É uma pena que esse velho problema ainda persista.

Porém, esteja ciente de que se você realmente usar avahi-daemon para algo, como localizar impressoras e scanners em sua rede, isso não funcionará mais.

Só tive o mesmo problema. o

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

fez o truque para mim também. Apenas no caso de você estar executando Ruby sob o rvm, aqui está o caminho a seguir:

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

"Thin" agora é uma ótima opção para executar localmente e no Heroku:

Site: http://code.macournoyer.com/thin/

Você pode usá-lo localmente, colocando em seu Gemfile:

gem "thin"

... e então execute bundle e inicie seu servidor com thin startou rails s.

Atualização no Heroku

Thin agora é considerado uma escolha ruim para Heroku. Mais informações aqui:

https://blog.heroku.com/archives/2013/4/3/routing_and_web_performance_on_heroku_a_faq

Sua recomendação:

Mude para um back-end da web concorrente, como Unicorn ou Puma no JRuby, que permite ao dinamômetro gerenciar sua própria fila de solicitações e evitar o bloqueio de solicitações longas.

Tive um problema vagamente semelhante que se manifestou ao acessar um servidor WEBrick por meio de uma VPN. Os pedidos levariam muito tempo, a maioria sem acontecer nada na transmissão. Já que nem mongrelnem thingems funcionavam com Ruby1.9 no Windows e não havia como eu me envolver em compilar coisas do código-fonte, eu precisava ficar com o WEBrick.

A correção foi definir o parâmetro de configuração DoNotReverseLookuppara true, ao criar o servidor WEBrick:

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

Você pode usar Apacheou instalar Thin. Em seu Gemfile:gem 'thin'

Além disso, você pode verificar a lista de servidores web para trilhos .

Estava tentando fazer isso com o webrick em 1.8.7 e não conseguia encontrar a configuração para alterar. No entanto, um truque que você pode usar é adicionar ao arquivo hosts do servidor que está executando o webrick o endereço IP que está tentando reverter a pesquisa.

Eu experimentei atrasos de 10 segundos freqüentemente com Sinatra. Este trecho resolveu para mim.

Adicione isto próximo ao topo do seu app.rbarquivo

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

Veja a fonte

Este é um antigo tópico de perguntas e respostas que me ajudou a resolver o :DoNotReverseLookupproblema em uma máquina virtual de desenvolvimento local e queria adicionar informações adicionais. Esta página da web explica o erro de regressão no núcleo Ruby que faz com que esse problema apareça para alguns; ênfase é minha; Resumindo, há uma solicitação de pull do GitHub para uma correção do núcleo Ruby para isso e esperançosamente será aprovado e mesclado em uma versão em breve do Ruby:

Depois de algumas horas de solução de problemas, descobriu-se que sim! Aparentemente, em algum momento ao longo da evolução da lib padrão do Ruby de 1.8.6 para 2.0.0, WEBrick adquiriu uma nova opção de configuração :DoNotReverseLookupque é definida como nilpadrão. Então, nas entranhas do código de processamento de solicitação do WEBrick, ele define o do_not_reverse_lookupsinalizador na instância do soquete de conexão de entrada com o valor de config[:DoNotReverseLookup]. Como esse valor é nil, o que é falso, o efeito é o mesmo que configurá-lo como false, substituindo o Socket.do_not_reverse_lookupsinalizador global . Portanto, a menos que você tenha: DoNotReverseLookup => truena configuração do WEBrick, a pesquisa reversa de DNS sempre acontecerá para cada nova conexão, potencialmente causando latência séria.

Relacionado a esta descoberta está uma solicitação de pull do GitHub do autor propondo como reparar o problema no código-fonte do Ruby WEBrick: Corrigir bug de regressão no WEBrick: Implementação da opção de configuração DoNotReverseLookup # 731

A solução, conforme descrito na solicitação, é alterar a linha 181 lib/webrick/server.rbdesta:

sock.do_not_reverse_lookup = config[:DoNotReverseLookup]

Para isso:

unless config[:DoNotReverseLookup].nil?

Compartilhando aqui se alguém tropeçar neste tópico bem considerado de perguntas / respostas e estiver interessado no progresso na resolução deste problema no núcleo Ruby. Esperançosamente, essa atração será mesclada ou o problema subjacente será tratado de alguma forma na próxima versão do Ruby; talvez 2.1.6?

Esta é uma resposta muito tardia, mas eu passei uma boa parte do dia depurando esse mesmo problema com Rails rodando em Vagrant. Alterar a pesquisa DNS reversa não melhorou de fato os tempos de solicitação. Uma combinação de duas coisas levou meu carregamento de página de aproximadamente 20 segundos a aproximadamente 3 segundos no modo de desenvolvimento:

Substitua WEBrick por mongrel. Tive que usar a versão de pré-lançamento ou não iria instalar:

sudo gem install mongrel --pre

Em seguida, adicione-o ao meu Gemfile para dev:

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

Iniciei meu servidor assim:

rails server mongrel -e development

Isso cortou alguns segundos, 5 ou 6 segundos, mas ainda era terrivelmente lento. Esta foi a cereja do bolo - adicione isso também ao Gemfile:

group :development do
  gem 'rails-dev-boost', :git => 'git://github.com/thedarkone/rails-dev-boost.git'
end

Não há DoNotReverseLookupopção no webrick Ruby 1.8.x. A solução é colocar:

Socket.do_not_reverse_lookup = true

em algum lugar no início do seu script.

Fonte: WEBrick e Socket.do_not_reverse_lookup: A Tale in Two Acts

Em minha situação provavelmente rara, funcionou depois de liberar meus iptables, isso não teve nenhum efeito colateral porque eu não tinha nenhuma regra personalizada (apenas o padrão do Ubuntu permite todos):

sudo iptables -F