Webrick reagiert sehr langsam. Wie kann man es beschleunigen?

Ich habe eine Rails-Anwendung, die ich auf meinem Server ausführe. Wenn ich zu einem Remotedesktop gehe und versuche, die Anwendung zu laden, benötigt der Server gut 3-4 Minuten, um mit einer einfachen HTML-Seite zu antworten. Wenn ich die Seite jedoch lokal auf den Server lade, wird die Seite in nur einer Sekunde angezeigt. Ich habe versucht, den Server von meinem Remotedesktop aus zu pingen, und die Pings werden in angemessener Zeit erfolgreich ausgeführt.

Dies alles scheint begonnen zu haben, nachdem ich den Basisclient von Oracle und SQLPLUS installiert habe. Sollte ich Oracle vermuten? Hat jemand etwas Ähnliches erlebt?

Ich habe das gleiche Problem hier (sogar ein Jahr später). Unter Linux müssen Sie Folgendes tun:

Suchen Sie nach der Datei /usr/lib/ruby/1.9.1/webrick/config.rb und bearbeiten Sie sie.

Ersetzen Sie die Leitung

:DoNotReverseLookup => nil,

mit

:DoNotReverseLookup => true,

Starten Sie Webrick neu und es wird wie ein Zauber funktionieren :)

Hatte das gleiche Problem. Für mich war dieser Beitrag die Lösung. Wenn Sie unter Ubuntu arbeiten, beenden Sie das Programm (oder deinstallieren Sie es) avahi-daemon. service avahi-daemon stopstoppt den Daemon.

Webrick fühlt sich jetzt sehr schnell an.

Das Problem hat einen alten Bericht in Rails Lighthouse , jedoch haben Ruby-on-Rails ihre Tickets nach Github verschoben seitdem . Ein bisschen bedauerlich, dass dieses alte Problem immer noch besteht.

Beachten Sie jedoch, dass , wenn Sie tatsächlich nutzen avahi-daemon für etwas, wie Drucker und Scanner zu finden , in Ihrem Netzwerk, das nicht mehr funktioniert.

Hatte gerade das gleiche Problem. Das

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

hat den Trick auch für mich gemacht. Nur für den Fall, dass Sie Rubin unter dem RVM laufen, ist hier der Weg zu gehen:

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

"Dünn" ist jetzt eine großartige Option, um beide lokal auszuführen und auf Heroku::

Website: http://code.macournoyer.com/thin/

Sie können es lokal verwenden, indem Sie Ihre Gemfile eingeben:

gem "thin"

... und dann Bundle ausführen und den Server mit thin startoder starten rails s.

Update auf Heroku

Dünn wird jetzt als schlechte Wahl für Heroku angesehen. Weitere Informationen hier:

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

Ihre Empfehlung:

Wechseln Sie zu einem gleichzeitigen Web-Backend wie Unicorn oder Puma auf JRuby, wodurch der Prüfstand seine eigene Anforderungswarteschlange verwalten und das Blockieren langer Anforderungen vermeiden kann.

Ich hatte ein vage ähnliches Problem, das sich beim Zugriff auf einen WEBrick-Server über ein VPN zeigte. Anfragen würden lange dauern, meistens ohne dass etwas auf dem Draht passiert. Da weder Ruby mongrelnoch thinGems mit Ruby1.9 unter Windows funktionierten und ich mich auf keinen Fall darauf einlassen konnte, Dinge aus dem Quellcode zu kompilieren, musste ich mich an WEBrick halten.

Das Update war den Konfigurationsparameter einstellen DoNotReverseLookupzu true, wenn die WEBrick Server zu erstellen:

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

Sie können verwenden Apacheoder installieren Thin. In Ihrer Gemfile:gem 'thin'

Sie können auch die Liste der Webserver auf Schienen überprüfen .

Ich habe versucht, dies mit webrick auf 1.8.7 zu tun und konnte die zu ändernde Konfiguration nicht finden. Ein Cheat, den Sie verwenden können, besteht darin, der Hosts-Datei des Servers, auf dem Webrick ausgeführt wird, die IP-Adresse hinzuzufügen, die versucht wird, die Suche umzukehren.

Bei Sinatra kam es häufig zu Verzögerungen von 10 Sekunden. Dieser Ausschnitt hat es für mich gelöst.

Fügen Sie dies oben in Ihrer app.rbDatei hinzu

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

Siehe Quelle

Dies ist ein alter Frage- und Antwort-Thread, der mir geholfen hat, das :DoNotReverseLookupProblem auf einer lokalen virtuellen Entwicklungsmaschine zu lösen, und der zusätzliche Informationen hinzufügen wollte. Auf dieser Webseite wird der Regressionsfehler in Ruby Core erläutert, der dazu geführt hat, dass dieses Problem bei einigen auftritt. Betonung liegt bei mir; Das lange und kurze an all dem ist, dass es eine GitHub-Pull-Anfrage für einen Ruby-Core-Fix gibt, der hoffentlich genehmigt und in einer baldigen Version von Ruby zusammengeführt wird:

Nach einigen Stunden der Fehlerbehebung stellte sich heraus, dass dies der Fall war! Anscheinend hat WEBrick irgendwo in der Entwicklung von Rubys Standardbibliothek von 1.8.6 auf 2.0.0 eine neue Konfigurationsoption erworben :DoNotReverseLookup, die nilstandardmäßig eingestellt ist. Dann setzt es tief im Bauch des WEBrick-Anforderungsverarbeitungscodes das do_not_reverse_lookupFlag für die Instanz des eingehenden Verbindungssockets auf den Wert von config[:DoNotReverseLookup]. Da dieser Wert nilfalsch ist, entspricht der Effekt dem Festlegen falsedes globalen Socket.do_not_reverse_lookupFlags. Sofern Sie nicht Folgendes haben: DoNotReverseLookup => trueIn Ihrer WEBrick-Konfiguration wird für jede neue Verbindung immer eine umgekehrte DNS-Suche durchgeführt, was möglicherweise zu einer schwerwiegenden Latenz führt.

Im Zusammenhang mit dieser Entdeckung steht eine GitHub-Pull-Anfrage des Autors, die vorschlägt, wie das Problem im Ruby WEBrick-Quellcode behoben werden kann: Behebung des Regressionsfehlers in der Implementierung der Konfigurationsoption # 731 von WEBrick: DoNotReverseLookup

Die in der Anforderung beschriebene Lösung besteht darin, Zeile 181 lib/webrick/server.rbvon dieser zu ändern :

sock.do_not_reverse_lookup = config[:DoNotReverseLookup]

Dazu:

unless config[:DoNotReverseLookup].nil?

Teilen Sie hier, wenn jemand über diesen angesehenen Frage- / Antwort-Thread stolpert und an den Fortschritten bei der Lösung dieses Problems in Ruby Core interessiert ist. Hoffentlich wird dieser Pull zusammengeführt oder das zugrunde liegende Problem wird in der nächsten Version von Ruby auf irgendeine Weise behandelt. vielleicht 2.1.6?

Dies ist eine sehr späte Antwort, aber ich habe einen Großteil des Tages damit verbracht, genau dieses Problem mit Rails zu debuggen, das auf Vagrant läuft. Das Ändern der Reverse-DNS-Suche hat die Anforderungszeiten überhaupt nicht verbessert. Durch eine Kombination aus zwei Dingen wurde meine Seite im Entwicklungsmodus von ~ 20 Sekunden auf ~ 3 Sekunden geladen:

Ersetzen Sie WEBrick durch Mischling. Ich musste die Vorabversion verwenden, sonst würde sie nicht installiert:

sudo gem install mongrel --pre

Dann füge es meiner Gemfile für Entwickler hinzu:

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

Habe meinen Server dann so gestartet:

rails server mongrel -e development

Das verkürzte ein paar Sekunden, 5 oder 6 Sekunden, aber es war immer noch furchtbar langsam. Dies war das i- Tüpfelchen - fügen Sie dies auch der Gemfile hinzu:

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

Es gibt keine DoNotReverseLookupOption in Ruby 1.8.x Webrick. Die Lösung lautet:

Socket.do_not_reverse_lookup = true

irgendwo am Anfang Ihres Skripts.

Quelle: WEBrick und Socket.do_not_reverse_lookup: Eine Geschichte in zwei Akten

In meiner wahrscheinlich seltenen Situation funktionierte es, nachdem ich meine iptables geleert hatte. Dies hatte keine Nebenwirkungen, da ich keine benutzerdefinierten Regeln hatte (nur das Standard-Ubuntu erlaubt alle):

sudo iptables -F