This project is archived and is in readonly mode.
New 2.3.3 app perf very poor from remote machine
Reported by Duncan Bayne | August 3rd, 2009 @ 07:57 AM
On my development machine (Compaq C700, running a recently updated deployment of Ubuntu 9.04 Desktop), newly created Rails 2.3.3 apps are very slow.
Repro Steps
- sudo gem install rails --version 2.3.3
- rails foo
- cd foo
- ruby script/generate scaffold Thingy
- rake db:migrate
- ruby script/server
At this point I see the following on the console:
=> Booting WEBrick => Rails 2.3.3 application starting on http://0.0.0.0:3000 => Call with -d to detach => Ctrl-C to shutdown server [2009-08-03 16:49:30] INFO WEBrick 1.3.1 [2009-08-03 16:49:30] INFO ruby 1.8.7 (2008-08-11) [i486-linux] [2009-08-03 16:49:35] INFO WEBrick::HTTPServer#start: pid=11951 port=3000
- from remote machine (on the same subnet, over a fast WLAN
connection) browse to http://MYIP:3000/thingies
- initial page load & subsequent refreshes typically take
> 10sec (seconds!) from hitting F5 to seeing the page
rendered
- from development machine, browse to http://127.0.0.1:3000/thingies
- initial page load & subsequent refreshes are practically instantaneous
I've attached the development.log from step 7 above; it looks in
order but may be of help.
Worth noting is that on the same machines, a newly-created Rails 2.2.2 performs perfectly well. Also, if I take an existing Rails 2.2.2 app and upgrade it to 2.3.3, it experiences the same perf issues, with page views slowing to ~ 10 seconds.
I have also reproduced this on our other dev box, a Mac Pro also running Ubuntu 9.04.
Configuration
OS:
Ubuntu 9.04 (updated as of today 03 July 2009)
Linux duncan-laptop 2.6.28-14-generic #47-Ubuntu SMP
Sat Jul 25 00:28:35 UTC 2009 i686 GNU/Linux
Local Gems:
actionmailer (2.3.3, 2.3.2, 2.2.2)
actionpack (2.3.3, 2.3.2, 2.2.2)
activerecord (2.3.3, 2.3.2, 2.2.2)
activeresource (2.3.3, 2.3.2, 2.2.2)
activesupport (2.3.3, 2.3.2, 2.2.2)
aslakhellesoy-webrat (0.3.2.2)
builder (2.1.2)
columnize (0.3.0)
cucumber (0.3.5)
diff-lcs (1.1.2)
gosu (0.7.13.3)
libxml-ruby (1.1.3)
linecache (0.43)
macaddr (1.0.0)
mislav-will_paginate (2.3.8)
nokogiri (1.2.3)
polyglot (0.2.5)
rack (1.0.0)
rails (2.3.3, 2.3.2, 2.2.2)
rake (0.8.7, 0.8.4)
rake-tasks (0.2)
rcov (0.8.1.2.0)
rspec (1.2.6)
rspec-rails (1.2.6)
ruby-debug (0.10.3)
ruby-debug-base (0.10.3)
term-ansicolor (1.0.3)
treetop (1.2.5)
uuid (2.0.1)
webrat (0.4.4)
Comments and changes to this ticket
-
Duncan Bayne August 3rd, 2009 @ 07:59 AM
Apologies for the formatting; I'm not used to any defect tracking system that uses anything other than plain text.
-
Duncan Bayne August 3rd, 2009 @ 08:13 AM
Also, Ruby version:
ruby 1.8.7 (2008-08-11 patchlevel 72) [i486-linux]
-
Duncan Bayne August 23rd, 2009 @ 03:09 AM
This is caused by the Ruby package on Ubuntu 9.04 being compiled with the pthreads option; see https://bugs.launchpad.net/ubuntu/+source/ruby1.8/+bug/307462. Apparently recompiling Ruby without the --enable-pthread flag fixes the problem.
-
sam.hendley December 18th, 2009 @ 08:40 PM
I would like to report that I tried this fix and it didn't help. I compiled ruby 1.8.8 from source on Ubunutu hardy and it didn't fix this issue. This seemed like a crazy reason to 10 second timeouts anyways so I dug a little deeper. I ran strace on the server program and saw that the delay was due to a reverse ip lookup that was timing out after 15 seconds, from strace:
write(4, “RESOLVE-ADDRESS 127.0.0.255\n”, 28) = 28
read(4, “-15 Timeout reached\n”, 1024) = 20googling on this I found this page http://qzdrproject.wordpress.com/2008/08/27/troubleshooting-network... which was having the same general issue and had the same strace output. They suggested turning off avahi demon which I did and then boom! everything is working as expected. Now I just need to figure out what that service was doing and if I can live without it.
This lookup can be disabled by turning off the "BasicSocket.do_not_reverse_lookup = true" flag in the socket class. Could that have been what changed between 2.2.2 and 2.3.x? Does that reverse lookup get used or is it just an unnecessary slow down that we throw away?
-
Roland Moriz April 11th, 2010 @ 04:36 AM
@sam
Looks to me that you've weird LAN setup with zeroconf/avahi trying to resolve the reversemapping of 127.0.0.255 all the time which isn't possible and leads into a timeout — you probably just want to fix the lookup (/etc/resolv.conf /etc/hosts /etc/nsswitch + your zeroconf settings).
Anyhow, disabling reverse lookup should be a good idea because it blocks even when it works. I'm suprised ruby's default was to do a lookup (crazy) until Feb 2010:
http://redmine.ruby-lang.org/issues/show/1811 and http://redmine.ruby-lang.org/repositories/revision/ruby-19?rev=26541
It still might be a good idea to change the rails code to speed up 1.8.7 users (even with working dns)
-
-
Mike Riley July 29th, 2010 @ 08:05 PM
- State changed from “new” to “stale”
- Importance changed from “” to “Low”
Hello,
Due to the date when this originally was entered and no further updates to it I am going to close this. If there are any further updates, feel free to reopen with more information.
Mike Riley
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>
Duncan Bayne
Jeremy Kemper
Mike Riley
Rohit Arondekar