Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'm using Ubuntu (Lucid Lynx) to learn Ruby On Rails. I'm running Ubuntu in VirtualBox (the host is Windows 7 Ultimate), using bridged networking.

When I run my Rails app and point the browser at it using localhost:3000, the app responds immediately and my page is rendered in a second or two.

However, if I use 10.0.0.5:3000 (where 10.0.0.5 is my IP address reported using ifconfig), the response from my rails app is incredibly slow - maybe 30 seconds or more for the server to respond and render the page.

This happens in both Firefox and Chrome. Also, when I hit the Rails app from the host (to test it in IE), I get the same slooooooow response.

Any ideas what might be going on? I've tried it with two different routers, and on two different networks (work and home) with the same result.

Cheers all.

share|improve this question
1  
Are other connections to the virtual Ubuntu box also very slow? How about connecting the other way, from the Ubuntu VM to the Windows host? –  CarlF Sep 1 '10 at 12:39
    
I can ping the Ubuntu guest from the Windows host, and the ping replies are immediate. Also, connections from the Ubuntu guest to the Windows host (eg to an IIS website on Windows) are fast. The only slowness is when I hit the Ubuntu Rails server using the IP address. Using localhost is fine. –  Lenny Marnham Sep 2 '10 at 7:34
    
I'm having the same problem, but no matter if I use 'localhost' or the numeric IP, the responses is terrible slow. It takes a couple of seconds to load each resource (an image, a js, whatever). I've tried mongrel, thin, unicorn... I guess the only solution is to use passenger under apache right? –  emzero Apr 14 '11 at 20:14
    
could be related to reverse dns lookups. –  artistoex Aug 29 '11 at 14:55
    
This article might provide an answer : stackoverflow.com/questions/1156759/… –  Etienne Feb 27 at 13:53

6 Answers 6

Try running

sudo service avahi-daemon stop

Also try setting WEBrick /usr/lib/ruby//webrick/config.rb

:DoNotReverseLookup => true

Also see: "Stackoverflow WEBrick slow from remote desktop"

share|improve this answer
    
+1 stopping Avahi had an immediate impact. Could you provide an explanation as to why? –  Amro Mar 17 '12 at 0:16
    
@Amro, not sure. http://mercenary-code.blogspot.co.uk suggested it and mentions deleting the symlink from /etc/rc3.d so it doesn't restart. This Lighthouse ticket mentions avahi trying to resolve the reversemapping of 127.0.0.255 causing a timeout. http://qzdrproject.wordpress.com did the digging in strace/wireshark to find the solution. –  James EJ Apr 9 '12 at 18:48
    
This worked for me, it does seem to be caused by a reverse lookup which eventually times out. –  Ed Bishop Jun 19 '13 at 22:17

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.

share|improve this answer

I've had this same problem occur under both VirtualBox and VMware. Not sure what the problem is... it acts like the Rails server is looking something up that has to be timed out? Rails server reports fast render times in log, but takes forever to respond to each request. Happens in both Rails 2.3.8 and Rails 3.0.3 for me on one particular Ubuntu instance (tried under both VirtualBox and VMware). I've had another Ubuntu VM on another box that didn't have the problem...

After frustratingly chasing this for some time, my solution is to use Phusion Passenger in development mode and Apache.

share|improve this answer

Warning: this is a non-answer (other than the suggestion just to use Passenger), but I'm documenting my own experience as well as some experiments that I did that hopefully help us come closer to a conclusion.

I have the exact same issue. It came up suddenly. I also have a similar observation to you on the ping front. My Ubuntu guest also runs a regular LAMP stack, and there are absolutely no service issues there. For what it's worth, it seems like unix_stream_data_wait is (mostly?) to blame for the hangup. I can't really parse what this means beyond the trivial or how to investigate further.

This seems to be independent of port number (moving rails to a lower port as in rails s -p 30 doesn't change the issue, and other services set to listen to port 3000 don't encounter the same service issues).

It also seems to be independent of the application code. I tried it with a bare rails app, and the delay reappeared.

The delay also seems to vary in duration, raising a potential problem with the hypothesis that Rails is timing out predicably.

Requests sent in the same "batch" seem to be fulfilled at the same time. This suggests that there's something in the interface between the Rails process and the network handler, where the interface is just damned slow but clears his plate when the transaction eventually does go through.

Overall, weird weird weird.

I just went with passenger instead.

share|improve this answer

This one is really strange. I've found out, that if I start rails server from putty responses are much faster, than if I start it from VirtualBox window...

share|improve this answer

If you are using WEBrick, you can try using Thin instead. Add thin to your Gemfile:

gem 'thin'

and install it by running:

bundle

Start the server by running:

thin start
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.