Ubuntu in Virtualbox - WEBrick-Webserver ist bei Verwendung einer lokalen IP-Adresse sehr langsam

Versuchen Sie zu laufen

sudo service avahi-daemon stop

Versuchen Sie auch, WEBrick /usr/lib/ruby//webrick/config.rb einzustellen

:DoNotReverseLookup => true

Siehe auch: "Stackoverflow WEBrick langsam vom Remote-Desktop"

It is WEBrick issue, no problems when you use other web servers.

I tried Mongrel and Thin with Ruby on Rails 3.0.x, both working great.

I suggest using Mongrel - simply add it to your Gemfile:

gem "mongrel" 

or you can set it only for development and test, not to break production:

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

Now start server same way as you did before and Mongrel starts instead of WEBrick.

If you prefer Thin, you need to start server with thin start or WEBrick will be started.

Ich hatte das gleiche Problem sowohl unter VirtualBox als auch unter VMware. Sie sind sich nicht sicher, was das Problem ist ... es verhält sich so, als würde der Rails-Server nach etwas suchen, das abgelaufen sein muss? Der Rails-Server meldet schnelle Renderzeiten im Protokoll, aber es dauert ewig, auf jede Anforderung zu antworten. Dies geschieht in beiden Rails 2.3.8 und in Rails 3.0.3 auf einer bestimmten Ubuntu-Instanz (versucht unter VirtualBox und VMware). Ich hatte eine andere Ubuntu VM auf einer anderen Box, die das Problem nicht hatte ...

Nachdem ich dies einige Zeit frustrierend verfolgt hatte, ist meine Lösung der Einsatz von Phusion Passenger im Entwicklungsmodus und Apache.

Achtung: Dies ist keine Antwort (abgesehen von dem Vorschlag, Passagiere zu verwenden), aber ich dokumentiere meine eigenen Erfahrungen sowie einige Experimente, die ich gemacht habe und die uns hoffentlich helfen, einer Schlussfolgerung näher zu kommen.

Ich habe genau das gleiche Problem. Es kam plötzlich auf. Ich habe auch eine ähnliche Beobachtung an der Ping-Front. Mein Ubuntu-Gast führt auch einen normalen LAMP-Stack aus, und es gibt absolut keine Serviceprobleme. Für das, was es wert ist, scheint unix_stream_data_waites (meistens?) Für den Hangup verantwortlich zu sein. Ich kann nicht wirklich analysieren, was dies über das Triviale hinaus bedeutet oder wie ich weiter nachforschen kann.

Dies scheint unabhängig von der Portnummer zu sein (das Verschieben der Schienen zu einem niedrigeren Port wie in rails s -p 30ändert das Problem nicht, und andere Dienste, die Port 3000 abhören, haben nicht die gleichen Serviceprobleme).

Es scheint auch unabhängig vom Anwendungscode zu sein. Ich habe es mit einer nackten Gleise-App ausprobiert, und die Verzögerung erschien wieder.

Die Verzögerung scheint ebenfalls in der Dauer zu variieren, was zu einem möglichen Problem mit der Hypothese führt, dass Rails vorhersehbar ein Zeitlimit hat.

Anfragen, die in derselben "Charge" gesendet werden, scheinen zur gleichen Zeit erfüllt zu sein. Dies deutet darauf hin, dass sich etwas in der Schnittstelle zwischen dem Rails-Prozess und dem Netzwerk-Handler befindet, bei dem die Schnittstelle verdammt langsam ist, sich aber von ihrem Platz befreit, wenn die Transaktion schließlich durchläuft.

Insgesamt komisch komisch komisch.

Ich bin nur mit dem Passagier gegangen .

Dieser ist wirklich seltsam. Ich habe herausgefunden, dass, wenn ich Schienen-Server von Putty-Antworten aus gestartet habe, die Antworten viel schneller sind, als wenn ich sie vom VirtualBox-Fenster aus starte ...

Wenn Sie WEBrick verwenden, können Sie stattdessen Thin verwenden. Dünne zu deinem Gemfile hinzufügen:

gem 'thin' 

und installieren Sie es, indem Sie Folgendes ausführen:

bundle 

Starten Sie den Server, indem Sie Folgendes ausführen:

thin start