Webrick tarda mucho en responder. ¿Cómo acelerarlo?

Tengo una aplicación Rails que estoy ejecutando en mi servidor. Cuando voy a un escritorio remoto e intento cargar la aplicación, el servidor tarda unos 3-4 minutos en responder con una simple página HTML. Sin embargo, cuando cargo la página localmente en el servidor, la página aparece en solo un segundo. Intenté hacer ping al servidor desde mi escritorio remoto y los pings se realizan correctamente en un período de tiempo razonable.

Todo esto parece haber comenzado después de que instalé el cliente básico de Oracle y SQLPLUS. ¿Debería sospechar de Oracle? ¿Alguien ha experimentado algo similar a esto?

Tener el mismo problema aquí (incluso un año después). En Linux tienes que hacer lo siguiente:

Busque el archivo /usr/lib/ruby/1.9.1/webrick/config.rb y edítelo.

Reemplazar la línea

:DoNotReverseLookup => nil,

con

:DoNotReverseLookup => true,

Reinicie webrick y funcionará de maravilla :)

Tuvo el mismo problema. Para mí, esta publicación tenía la solución. Si está en Ubuntu, detenga (o desinstale) el archivo avahi-daemon. service avahi-daemon stopdetiene el daemon.

Webrick ahora se siente muy rápido.

El problema tiene un informe antiguo en Rails Lighthouse , sin embargo, Ruby-on-Rails ha movido sus tickets a github desde entonces; Es un poco lamentable que este viejo problema persista todavía.

Sin embargo, tenga en cuenta que si realmente lo usa avahi-daemon para algo, como encontrar impresoras y escáneres en su red, eso ya no funcionará.

Solo tuve el mismo problema. los

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

hizo el truco para mí también. En caso de que esté ejecutando ruby ​​debajo del rvm, aquí está el camino a seguir:

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

"Thin" es ahora una excelente opción para ejecutar localmente y en Heroku:

Sitio web: http://code.macournoyer.com/thin/

Puede usarlo localmente colocando en su Gemfile:

gem "thin"

... y luego ejecute bundle e inicie su servidor con thin starto rails s.

Actualización sobre Heroku

Thin ahora se considera una mala elección para Heroku. Más información aquí:

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

Su recomendación:

Cambie a un backend web concurrente como Unicorn o Puma en JRuby, lo que le permite al banco de pruebas administrar su propia cola de solicitudes y evitar el bloqueo de solicitudes largas.

Tuve un problema vagamente similar que se manifestó al acceder a un servidor WEBrick a través de una VPN. Las solicitudes tomarían mucho tiempo, la mayoría sin que ocurriera nada en el cable. Como ni mongrelni thingems funcionaban con Ruby1.9 en Windows y no había forma de que me enredara compilando cosas desde la fuente, necesitaba seguir con WEBrick.

La solución fue establecer el parámetro de configuración DoNotReverseLookupen true, al crear el servidor WEBrick:

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

Puede usar Apacheo instalar Thin. En su Gemfile:gem 'thin'

También puede consultar la lista de servidores web para raíles .

Estaba tratando de hacer esto con webrick en 1.8.7 y no pude encontrar la configuración para cambiar. Sin embargo, un truco que puede usar es agregar al archivo de hosts del servidor que está ejecutando webrick la dirección IP que está tratando de revertir la búsqueda.

Experimenté retrasos de 10 segundos con frecuencia con Sinatra. Este fragmento lo resolvió por mí.

Agregue esto cerca de la parte superior de su app.rbarchivo

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

Ver fuente

Este es un antiguo hilo de preguntas y respuestas que me ayudó a resolver el :DoNotReverseLookupproblema en una máquina virtual de desarrollo local y quería agregar información adicional. Esta página web explica el error de regresión en el núcleo de Ruby que llevó a que apareciera este problema para algunos; el énfasis es mío; En el corto plazo de todo esto, hay una solicitud de extracción de GitHub para una corrección del núcleo de Ruby para esto y, con suerte, se aprobará y se fusionará en una versión próxima de Ruby:

Después de unas horas de resolución de problemas, resultó que sí. Aparentemente, en algún momento de la evolución de la biblioteca estándar de Ruby de 1.8.6 a 2.0.0, WEBrick adquirió una nueva opción de configuración :DoNotReverseLookupque está configurada nilde forma predeterminada. Luego, en lo más profundo del código de procesamiento de solicitudes de WEBrick, establece la do_not_reverse_lookupbandera en la instancia del socket de conexión entrante en el valor de config[:DoNotReverseLookup]. Dado que este valor es nilfalso, el efecto es el mismo que establecerlo en false, anulando la Socket.do_not_reverse_lookupbandera global . Entonces, a menos que tenga: DoNotReverseLookup => trueen su configuración de WEBrick, la búsqueda de DNS inversa siempre ocurrirá para cada nueva conexión, lo que podría causar una latencia grave.

Relacionado con este descubrimiento hay una solicitud de extracción de GitHub del autor que propone cómo reparar el problema en el código fuente de Ruby WEBrick: Corregir el error de regresión en la implementación de la opción de configuración de WEBrick: DoNotReverseLookup # 731

La solución como se describe en la solicitud es cambiar la línea 181 lib/webrick/server.rbde esto:

sock.do_not_reverse_lookup = config[:DoNotReverseLookup]

A esto:

unless config[:DoNotReverseLookup].nil?

Compartiendo aquí si alguien se tropieza con este hilo de preguntas / respuestas bien considerado y está interesado en el progreso en la resolución de este problema en Ruby Core. Con suerte, este tirón se fusionará o el problema subyacente se tratará de alguna manera en la próxima versión de Ruby; tal vez 2.1.6?

Esta es una respuesta muy tardía, pero pasé una buena parte del día depurando este mismo problema con Rails ejecutándose en Vagrant. Cambiar la búsqueda de DNS inversa en realidad no mejoró los tiempos de solicitud en absoluto. Una combinación de dos cosas llevó la carga de mi página de ~ 20 segundos a ~ 3 segundos en modo de desarrollo:

Reemplace WEBrick con mestizo. Tuve que usar la versión preliminar o no se instalaría:

sudo gem install mongrel --pre

Luego agréguelo a mi Gemfile para dev:

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

Entonces comencé mi servidor así:

rails server mongrel -e development

Eso cortó unos segundos, 5 o 6 segundos, pero aún así fue terriblemente lento. Esta fue la guinda del pastel ; agregue esto también al Gemfile:

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

No hay ninguna DoNotReverseLookupopción en ruby ​​1.8.x webrick. La solución es poner:

Socket.do_not_reverse_lookup = true

en algún lugar al principio de su guión.

Fuente: WEBrick y Socket.do_not_reverse_lookup: A Tale in Two Acts

En mi situación probablemente rara, funcionó después de vaciar mis iptables, esto no tuvo ningún efecto secundario porque no tenía reglas personalizadas (solo el Ubuntu predeterminado permite todo):

sudo iptables -F