Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

This project is archived and is in readonly mode.

New 2.3.3 app perf very poor from remote machine

#2987

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

  1. sudo gem install rails --version 2.3.3
  2. rails foo
  3. cd foo
  4. ruby script/generate scaffold Thingy
  5. rake db:migrate
  6. 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

  1. from remote machine (on the same subnet, over a fast WLAN connection) browse to http://MYIP:3000/thingies
  2. initial page load & subsequent refreshes typically take > 10sec (seconds!) from hitting F5 to seeing the page rendered
  3. from development machine, browse to http://127.0.0.1:3000/thingies
  4. 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 scaffold templates include tab characters-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)

Reported by Duncan Bayne · August 3rd, 2009 @ 07:57 AM

State: stale
Milestone: none
Assigned to: nobody
Importance: Low

Activity

  1. Duncan Bayne
    Duncan Bayne

    Apologies for the formatting; I'm not used to any defect tracking system that uses anything other than plain text.

    August 3rd, 2009 @ 07:59 AM

  2. Duncan Bayne
    Duncan Bayne

    Also, Ruby version:

    ruby 1.8.7 (2008-08-11 patchlevel 72) [i486-linux]

    August 3rd, 2009 @ 08:13 AM

  3. Duncan Bayne
    Duncan Bayne

    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.

    August 23rd, 2009 @ 03:09 AM

  4. sam.hendley
    sam.hendley

    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) = 20

    googling 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?

    December 18th, 2009 @ 08:40 PM

  5. Roland Moriz
    Roland Moriz

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

    April 11th, 2010 @ 04:36 AM

  6. Rohit Arondekar
    Rohit Arondekar

    Any updates to this ticket?

    June 16th, 2010 @ 02:49 PM

  7. Mike Riley
    Mike Riley
    • 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

    July 29th, 2010 @ 08:05 PM