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

J'ai une application Rails 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 bonnes minutes pour répondre avec une simple page HTML. 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 requêtes ping réussissent dans un laps de temps raisonnable.

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

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 :)

Avait le même problème. Pour moi, ce post était la solution. Si vous êtes sur Ubuntu, arrêtez (ou désinstallez) le avahi-daemon. service avahi-daemon stoparrê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; Un peu dommage que ce vieux problème persiste encore.

Sachez cependant que si vous utilisez réellement avahi-daemonpour quelque chose, comme trouver des imprimantes et des scanners sur votre réseau, cela ne fonctionnera plus.

J'ai juste eu le même problème. le

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

a fait l'affaire pour moi aussi. Juste au cas où vous utiliseriez ruby ​​sous le rvm, voici le chemin à suivre:

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

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

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

Vous pouvez l'utiliser localement en mettant dans votre Gemfile:

gem "thin"

... puis exécutez bundle et démarrez votre serveur avec thin startou rails s.

Mise à jour sur Heroku

Thin est maintenant considéré comme un mauvais choix 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, qui permet au dyno de gérer sa propre file d'attente de demandes et d'éviter le blocage sur de longues demandes.

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 sur le fil. Puisque ni mongrelni les thingemmes ne fonctionnaient avec Ruby1.9 sur Windows et qu'il n'y avait aucun moyen de me mêler de compiler des éléments à partir des sources, je devais m'en tenir à WEBrick.

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

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

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

Vous pouvez également consulter la liste des serveurs Web pour les rails .

J'essayais de le faire avec webrick sur 1.8.7 et je n'ai pas trouvé 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 tente d'inverser la recherche.

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

Ajoutez ceci en haut de votre app.rbfichier

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 la source

Il s'agit d'un ancien fil de questions et réponses qui m'a aidé à résoudre le :DoNotReverseLookupproblème sur une machine virtuelle de développement local et qui souhaitait ajouter des informations supplémentaires. Cette page Web explique l'erreur de régression dans Ruby core qui a conduit à l'apparition de ce problème pour certains; l'accent est le mien; En bref, il y a une demande de tirage GitHub pour un correctif du noyau Ruby à ce sujet et j'espère qu'elle sera approuvée et fusionnée 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 au cours de l'évolution de la bibliothèque standard de Ruby de la 1.8.6 à la 2.0.0, WEBrick a acquis une nouvelle option de configuration :DoNotReverseLookupdéfinie nilpar défaut. Ensuite, au plus profond du code de traitement des requêtes de WEBrick, il définit l' do_not_reverse_lookupindicateur de l'instance de socket de connexion entrante sur la valeur config[:DoNotReverseLookup]. Étant donné que cette valeur est nil, ce qui est faux, l'effet est le même que de la définir sur false, en remplaçant l' Socket.do_not_reverse_lookupindicateur global . Donc, sauf si vous avez: DoNotReverseLookup => truedans votre configuration WEBrick, la recherche DNS inversée se produira toujours pour chaque nouvelle connexion, ce qui pourrait entraîner une latence importante.

Lié à cette découverte est une demande d'extraction GitHub de l'auteur proposant comment réparer le problème dans le code source de 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 à lib/webrick/server.rbpartir de ceci:

sock.do_not_reverse_lookup = config[:DoNotReverseLookup]

Pour ça:

unless config[:DoNotReverseLookup].nil?

Partage ici si quelqu'un trébuche sur ce fil de questions / réponses bien considéré et est intéressé par les progrès réalisé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é d'une manière ou d'une autre dans la prochaine version de Ruby; peut-être 2.1.6?

C'est une réponse très tardive mais j'ai passé une bonne partie de la journée à déboguer ce même problème avec Rails fonctionnant sur Vagrant. La modification de la recherche DNS inversée n'a pas du tout amélioré les temps de demande. Une combinaison de deux choses a fait passer 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 s'installerait pas:

sudo gem install mongrel --pre

Ensuite, ajoutez-le à mon Gemfile pour dev:

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

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

rails server mongrel -e development

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

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

Il n'y a pas d' DoNotReverseLookupoption 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: Une histoire en deux actes

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

sudo iptables -F