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


88

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?


2
Peut-être que cela devrait maintenant être déplacé vers serverfault?
Prof. Falken

Ce n'est pas nécessaire, cela peut être résolu en modifiant simplement une ligne dans un fichier de configuration
Mosty Mostacho

2
@AmigableClarkKant Webrick est plus un outil de développement, il semble donc préférable de rester sur SO.
David

bonté, et tout au long j'ai attribué le problème à vmware, brûler en enfer webrick :(
prusswan

Réponses:


139

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


21
Travaillé! J'ai eu des problèmes avec Webrick étant lent lors de la diffusion de contenu statique à partir d'un autre ordinateur de notre réseau local. Cela l'a résolu. La seule différence était que config.rb était dans: ~ / .rvm / rubies / ruby-1.9.2-p180 / lib / ruby ​​/ 1.9.1 / webrick / config.rb - car nous utilisons RVM.
Slobodan Kovacevic

btw, je n'avais pas cette clé, alors je l'ai juste ajoutée et cela a fonctionné
ecoologic

où l'avez-vous ajouté? quelle section?
Abe Petrillo

Il est censé être dans la section Général selon ruby-doc.org/stdlib/libdoc/webrick/rdoc/classes/WEBrick/… .
David Grayson

10
La version de ruby ​​que j'ai est ruby-1.8.7-p330 et il ne semble pas avoir l'option DoNotReverseLookup. La chaîne "DoNotReverseLookup" n'apparaît pas dans le fichier config.rb de webrick ou ailleurs dans ~ / .rvm / rubies / ruby-1.8.7-p330 / lib / ruby ​​/ 1.8. Existe-t-il un moyen efficace de résoudre ce problème dans ruby-1.8.7-p330?
David Grayson

36

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.


1
Merci beaucoup!! Cela a résolu mon problème sur Ubuntu 11.04 / 11.10 / 12.04
SMMousavi

1
Eh bien, cette réponse semble être le héros méconnu pour moi!
PCoder

1
Cela l'a fait pour moi aussi. Exécution d'une ancienne application (1.8.7) sur Ubuntu 13.04
TerryS

1
cette solution me met en fait des problèmes car en arrêtant cela, les services réseau deviennent fous! consultez l'url suivante: forums.fedoraforum.org/showthread.php?t=124837
Isaiyavan Babu Karan

23

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

1
Merci! Avant de trouver votre réponse, j'ai cherché .rvm et je n'ai pas trouvé webrick, et j'ai changé celui / usr / lib et cela n'a pas aidé. Cela a fonctionné.
B Seven du

@KenBarber À peu près sûr que ce n'est pas une bonne direction, mais pour avoir un joli et petit cycle de développement, il est normal de faire juste cette modification à votre installation RVM locale. Et au fait, c'est juste votre profil d'utilisateur, vous ne dérangerez personne d'autre ...
Kjellski

1
@Kjellski vous avez peut-être raison, mais cela ne persiste pas lors des mises à niveau, ni une solution que vous pouvez facilement transmettre à vos collègues développeurs. Peut-être qu'un patch de singe sur Rails dans ce cas est préférable de hausser les épaules . Quoi qu'il en soit, c'est corrigé maintenant: github.com/rails/rails/commit/… ...
Ken Barber

15

"Thin" est désormais 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 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.


Une solution parfaite en ne changeant pas les codes ou quoi que ce soit dans le système.
Fernando Kosh

Il s'avère que Sinatra utilise automatiquement thin au lieu de webrick s'il est installé. Tout ce que j'avais à faire c'est gem install thin. Voir sinatrarb.com/intro.html Il est également recommandé d'exécuter gem install thin, que Sinatra récupérera si disponible. EDIT: Améliorations drastiques des performances. De 1,3 s à 0,05 s.
GuiSim

6

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, ...}


2

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.


Génial. C'est mieux que d'éditer un fichier webrick qui doit être modifié après chaque mise à jour.
Petr

Dans mon cas, l'entrée à ajouter (pour l'invité Linux exécutant webrick) serait l'adresse IP de l'hôte Windows
prusswan

2

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


1

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?


0

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


0

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
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.