Webrick es muy lento en responder. ¿Cómo acelerarlo?

Question

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 buenos 3-4 minutos en responder con una página HTML simple. 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 están teniendo éxito en un tiempo razonable.

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

Answer 1

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 parte sin que ocurra nada en el cable. Como ni mongrel ni thin gemas trabajaron con Ruby1.9 en Windows y no había manera de que me involucrara en la compilación de cosas desde el origen, tenía que seguir con WEBrick.

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

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

Answer 2

Tener el mismo tema aquí (incluso un año más tarde). En Linux debe hacer lo siguiente:

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

reemplace la línea

:DoNotReverseLookup => nil, 

con

:DoNotReverseLookup => true, 

WEBrick Reiniciar y que funcionará como un encanto :)

Answer 3

Sólo tenían el mismo problema. El

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

hizo el truco para mí también. Por si acaso estás corriendo rubí bajo la RVM, aquí es el camino a seguir para:

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

Answer 4

tenía el mismo problema. Para mí, this post tenía la solución. Si está en Ubuntu, detenga (o desinstale) el avahi-daemon. service avahi-daemon stop detiene al daemon.

Webrick ahora se siente muy rápido.

El problema tiene un old report in Rails Lighthouse, sin embargo, Ruby-on-Rails se ha movido their tickets to github desde entonces; Es desafortunado que este viejo problema persista aún.

Tenga en cuenta sin embargo, que si realmente el uso avahi-daemon por algo, como finding printers and scanners en la red, que no va a funcionar más.

Answer 5

Está tratando de hacer esto con webrick en 1.8.7 y no hemos podido encontrar la configuración para cambiar. Sin embargo, un truco que puede usar es agregar al archivo de hosts del servidor que se ejecuta, abrimos la dirección IP que está tratando de buscar de forma inversa.

Answer 6

"fino" es ahora una gran opción para el funcionamiento tanto a nivel local y en Heroku :

En Heroku: https://devcenter.heroku.com/articles/rails3#webserver

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

Usted puede utilizar de forma local, poniendo en su Gemfile:

gem "thin" 

... y luego ejecute el paquete e inicie su servidor con thin start o rails s.

Actualización sobre Heroku

delgada ahora se considera una mala elección de 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:

Cambiar a una secundaria de web concurrente como unicornio o Puma en JRuby, lo que permite que el banco de pruebas para gestionar su propia cola de solicitudes y evitar el bloqueo de larga peticiones.

Answer 7

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

O puede consultar la lista de web-servers for rails.

Answer 8

En mi probablemente situación poco frecuente, después de trabajado, tiraba mis iptables, esto no tiene ningún efecto secundario porque no tenía ninguna reglas personalizadas (sólo el defecto de Ubuntu permite todo):

sudo iptables -F 

Answer 9

Experimenté retrasos de 10 segundos con frecuencia con Sinatra. Este fragmento me lo resolvió.

Añadir este cerca de la parte superior de su archivo app.rb

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 source

Answer 10

Ésta es una respuesta muy tarde, pero pasé una buena parte del día de depuración este mismo problema con los carriles que se ejecuta en Vagrant . Cambiar la búsqueda DNS inversa no mejoró en absoluto los tiempos de solicitud. Una combinación de dos cosas llevó mi carga de página de ~ 20 segundos a ~ 3 segundos en el modo de desarrollo:

Reemplace WEBrick con mongrel.Tenía que usar la versión preliminar o no sería instalar:

sudo gem install mongrel --pre 

después añadirlo a mi Gemfile para dev:

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

Comienza mi servidor de esta manera a continuación:

rails server mongrel -e development 

Eso cortó unos segundos, 5 o 6 segundos, pero aún era terriblemente lento. Esta fue la guinda del pastel - añadir esto también a la Gemfile:

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

Answer 11

No hay ninguna opción en DoNotReverseLookup WEBrick ruby ​​1.8.x. La solución es poner:

Socket.do_not_reverse_lookup = true 

en algún lugar al comienzo de la secuencia de comandos.

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

Answer 12

Ésta es una vieja pregunta y respuesta hilo que me ayudó a resolver el problema :DoNotReverseLookup en una máquina virtual de desarrollo local y quería añadir información adicional. This web page explains the regression error en Ruby core que hace que este problema aparezca para algunos; el énfasis es mío; el largo de un corto de todo esto es que hay una solicitud de extracción de GitHub para un núcleo fijo Ruby a esto y es de esperar que se apruebe y se fusionó en un comunicado de pronto-ish de Ruby:

Después de unas horas de solución de problemas, ¡resultó que sí! Aparentemente, en algún lugar a lo largo de la evolución de la lib estándar de Ruby de 1.8.6 a 2.0.0, WEBrick adquirió una nueva opción de configuración :DoNotReverseLookup que está configurada en nil de forma predeterminada. Luego, en el interior de las entrañas del código de procesamiento de solicitud de WEBrick, establece el indicador do_not_reverse_lookup en la instancia del socket de conexión entrante con el valor config[:DoNotReverseLookup]. Dado que este valor es nil, que es falso, el efecto es el mismo que establecerlo en false, , anulando el indicador global Socket.do_not_reverse_lookup. Entonces, a menos que tenga: DoNotReverseLookup => true en su configuración de WEBrick, revertir La búsqueda de DNS siempre ocurrirá para cada conexión nueva, potencialmente causando latencia grave.

relacionada a este descubrimiento es a GitHub pull request from the author proponer cómo reparar el problema en el código fuente de Ruby WEBrick: Fix regression bug in WEBrick's :DoNotReverseLookup config option implementation #731

La solución tal como se indica en la petición es para cambiar la línea 181 en lib/webrick/server.rb de esto:

sock.do_not_reverse_lookup = config[:DoNotReverseLookup] 

a esto:

unless config[:DoNotReverseLookup].nil? 

Compartiendo aquí si alguien tropieza con este hilo de pregunta/respuesta bien considerado y está interesado en el progreso para resolver este problema en Ruby core. Esperemos que este tirón se fusione o el problema subyacente se trate de alguna manera en el próximo lanzamiento de Ruby; tal vez 2.1.6?