web-dev-qa-db-fra.com

Webrick est très lent à répondre. Comment l'accélérer?

J'ai une Rails application que j'exécute sur mon serveur. Lorsque je vais sur un bureau distant et que je tente de charger l'application, le serveur prend 3 à 4 minutes pour répondre avec un page HTML simple. Cependant, lorsque je charge la page localement sur le serveur, la page s'affiche en une seconde. J'ai essayé d'envoyer une requête ping au serveur à partir de mon bureau distant et les pings sont réussis dans un délai raisonnable.

Tout cela semble avoir commencé après avoir installé le client de base d'Oracle et SQLPLUS. Dois-je soupçonner Oracle? Quelqu'un a-t-il vécu quelque chose de similaire à cela?

ruby-on-railsoraclesqlpluswebrick
89
Crypto

Avoir le même problème ici (même un an plus tard). Sous Linux, vous devez faire ce qui suit:

Recherchez le fichier /usr/lib/Ruby/1.9.1/webrick/config.rb et modifiez-le.

Remplacez la ligne

:DoNotReverseLookup => nil,

avec

:DoNotReverseLookup => true,

Redémarrez webrick et cela fonctionnera comme un charme :)

140
Mosty Mostacho

Eu le même problème. Pour moi, ce post a tenu la solution. Si vous êtes sur Ubuntu, arrêtez (ou désinstallez) le avahi-daemon. service avahi-daemon stop arrête le démon.

Webrick se sent maintenant très rapide.

Le problème a un ancien rapport dans Rails Lighthouse , cependant, Ruby-on-Rails a déplacé leurs tickets vers github depuis lors; Kind regrettable que ce vieux problème persiste encore.

Sachez cependant que si vous utilisez avahi-daemon pour quelque chose, comme recherche d'imprimantes et de scanners sur votre réseau, qui ne fonctionnera plus.

36
Prof. Falken

Juste eu le même problème. le

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

a fait l'affaire pour moi aussi. Juste au cas où vous utilisez Ruby sous le rvm, voici le chemin à parcourir:

~/.rvm/rubies/Ruby-<version>/lib/Ruby/<version>/webrick/config.rb
23
Kjellski

"Thin" est maintenant une excellente option pour exécuter les deux localement et sur Heroku:

Sur Heroku: https://devcenter.heroku.com/articles/Rails3#webserver

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

Vous pouvez l'utiliser localement en mettant votre Gemfile:

gem "thin"

... puis exécutez bundle et démarrez votre serveur avec thin start ou Rails s.

Mise à jour sur Heroku

Thin est maintenant considéré comme un choix mauvais pour Heroku. Plus d'informations ici:

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

Leur recommandation:

Basculez vers un backend Web simultané comme Unicorn ou Puma sur JRuby, ce qui permet au dyno de gérer sa propre file d'attente de demandes et d'éviter le blocage sur les longues demandes.

15
Jamon Holmgren

J'ai eu un problème vaguement similaire qui s'est manifesté lors de l'accès à un serveur WEBrick via un VPN. Les demandes prendraient beaucoup de temps, la plupart sans rien se passer sur le fil. Étant donné que ni les gemmes mongrel ni thin ne fonctionnaient avec Ruby1.9 sur Windows et qu'il n'y avait aucun moyen que je m'implique dans la compilation de trucs à partir de la source, je devais m'en tenir à WEBrick.

Le correctif consistait à définir le paramètre de configuration DoNotReverseLookup sur true, lors de la création du serveur WEBrick:

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

Vous pouvez utiliser Apache ou installer Thin. Dans votre Gemfile: gem 'thin'

Ou vous pouvez consulter la liste des serveurs Web pour Rails .

5
Matz Heri

J'ai connu des retards de 10 secondes fréquemment avec Sinatra. Cet extrait de code l'a résolu pour moi.

Ajoutez ceci près du haut de votre app.rb fichier

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

Voir source

2
neoneye

J'essayais de le faire avec webrick sur 1.8.7 et je n'ai pas pu trouver la configuration à changer. Cependant, une astuce que vous pouvez utiliser consiste à ajouter au fichier hosts du serveur qui exécute webrick l'adresse IP qu'il essaie d'inverser la recherche.

2
patrickdavey

Ceci est un ancien fil de questions et réponses qui m'a aidé à résoudre le :DoNotReverseLookup problème sur une machine virtuelle de développement local et souhaitait ajouter des informations supplémentaires. Cette page Web explique l'erreur de régression in Ruby core qui conduit à ce problème apparaissant pour certains; l'accent est à moi; le long un court de tout cela est là est une requête d'extraction GitHub pour un Ruby correctif principal à cela et j'espère qu'il sera approuvé et fusionné dans une version bientôt-ish de Ruby:

Après quelques heures de dépannage, il s'est avéré que c'était le cas! Apparemment, quelque part dans l'évolution de la bibliothèque standard de Ruby de 1.8.6 à 2.0.0, WEBrick a acquis une nouvelle option de configuration :DoNotReverseLookup qui est défini sur nil par défaut. Puis, au plus profond des entrailles du code de traitement des demandes de WEBrick, il définit le do_not_reverse_lookup drapeau sur l'instance de socket de connexion entrante à la valeur de config[:DoNotReverseLookup]. Étant donné que cette valeur est nil, ce qui est faux, l'effet est le même que la définir sur false, en remplaçant le global Socket.do_not_reverse_lookup drapeau. Donc, sauf si vous avez: DoNotReverseLookup => true dans votre configuration WEBrick, une recherche DNS inversée se produira toujours pour chaque nouvelle connexion, ce qui pourrait entraîner une latence grave.

Lié à cette découverte est ne requête pull GitHub de l'auteur proposant comment réparer le problème dans le code source Ruby WEBrick: Correction d'un bug de régression dans WEBrick's : Implémentation de l'option de configuration DoNotReverseLookup # 731

La solution décrite dans la demande consiste à modifier la ligne 181 dans lib/webrick/server.rb à partir de ceci:

sock.do_not_reverse_lookup = config[:DoNotReverseLookup]

Pour ça:

unless config[:DoNotReverseLookup].nil?

Partager ici si quelqu'un tombe sur ce fil de questions/réponses bien considéré et est intéressé par les progrès dans la résolution de ce problème dans Ruby core. Espérons que cette attraction sera fusionnée ou que le problème sous-jacent sera traité dans d'une certaine façon dans la prochaine version de Ruby; peut-être 2.1.6?

1
JakeGould

Il s'agit d'une réponse très tardive, mais j'ai passé une bonne partie de la journée à déboguer ce problème avec Rails exécuté sur Vagrant. La modification de la recherche DNS inversée n'a pas amélioré les temps de demande. la combinaison de deux choses a pris le chargement de ma page de ~ 20 secondes à ~ 3 secondes en mode développement:

Remplacez WEBrick par bâtard. J'ai dû utiliser la version préliminaire ou elle ne serait pas installée:

Sudo gem install mongrel --pre

Ajoutez-le ensuite à mon Gemfile pour dev:

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

J'ai ensuite démarré mon serveur comme ceci:

Rails server mongrel -e development

Cela a coupé quelques secondes, 5 ou 6 secondes, mais c'était encore terriblement lent. C'était la cerise sur le gâtea - ajoutez ceci aussi au Gemfile:

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

Dans ma probablement situation rare, cela a fonctionné après avoir vidé mes iptables, cela n'a eu aucun effet secondaire parce que je n'avais pas de règles personnalisées (juste Ubuntu par défaut permet tout):

Sudo iptables -F
0
Nabil Kadimi

Il n'y a pas d'option DoNotReverseLookup dans Ruby 1.8.x webrick. La solution est de mettre:

Socket.do_not_reverse_lookup = true

quelque part au début de votre script.

Source: WEBrick et Socket.do_not_reverse_lookup: Un conte en deux actes

0
ohho