Rails development server is slow and takes a long time to load a simple page

Question

There are similar threads about Rails being slow in development mode, but none of the solutions in those threads has made any difference for me. I've tried installing gems that boost performance and mucking around with config files, but have had no success.

I'm just starting with Rails, and so I'm running the startup application in the "Getting Started with Rails" guide, which is a little blog. I've installed Ruby 1.9.3 and Rails 3.2.13, as recommended. I'm running on OS/X 10.7.5.

When loading the start page of the tutorial app, which is literally just 1 line of text and 1 link, it takes 20-40 seconds. Every subsequent request to any page take 20-40 seconds. However, when I take a look at the server logs, nothing that Rails is doing seems to be taking long. It's the time in-between the events in the logs that is taking up all the time. Being a beginner in Rails I have no idea how to debug this.

For example:

Started GET "/posts/1" for 127.0.0.1 at 2013-05-24 17:39:35 -0400
Processing by PostsController#show as HTML
  Parameters: {"id"=>"1"}
  Post Load (36.9ms)  SELECT "posts".* FROM "posts" WHERE "posts"."id" = ? LIMIT 1  [["id", "1"]]
  Comment Load (24.3ms)  SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = 1
  Rendered comments/_comment.html.erb (0.9ms)
  Rendered comments/_form.html.erb (25.8ms)
  Rendered posts/show.html.erb within layouts/application (158.5ms)
Completed 200 OK in 274ms (Views: 201.0ms | ActiveRecord: 61.9ms)


Started GET "/assets/home.css?body=1" for 127.0.0.1 at 2013-05-24 17:39:52 -0400
RailsDevTweaks: Skipping ActionDispatch::Reloader hooks for this request.
Served asset /home.css - 304 Not Modified (0ms)
[2013-05-24 17:39:52] WARN  Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true


Started GET "/assets/posts.css?body=1" for 127.0.0.1 at 2013-05-24 17:40:09 -0400
RailsDevTweaks: Skipping ActionDispatch::Reloader hooks for this request.
Served asset /posts.css - 304 Not Modified (0ms)
[2013-05-24 17:40:09] WARN  Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true


Started GET "/assets/jquery.js?body=1" for 127.0.0.1 at 2013-05-24 17:40:12 -0400
RailsDevTweaks: Skipping ActionDispatch::Reloader hooks for this request.
Served asset /jquery.js - 304 Not Modified (0ms)
[2013-05-24 17:40:12] WARN  Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true


Started GET "/assets/scaffolds.css?body=1" for 127.0.0.1 at 2013-05-24 17:40:16 -0400
RailsDevTweaks: Skipping ActionDispatch::Reloader hooks for this request.
Served asset /scaffolds.css - 304 Not Modified (0ms)
[2013-05-24 17:40:16] WARN  Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true


Started GET "/assets/jquery_ujs.js?body=1" for 127.0.0.1 at 2013-05-24 17:40:19 -0400
RailsDevTweaks: Skipping ActionDispatch::Reloader hooks for this request.
Served asset /jquery_ujs.js - 304 Not Modified (0ms)
[2013-05-24 17:40:19] WARN  Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true


Started GET "/assets/home.js?body=1" for 127.0.0.1 at 2013-05-24 17:40:21 -0400
RailsDevTweaks: Skipping ActionDispatch::Reloader hooks for this request.
Served asset /home.js - 304 Not Modified (0ms)
[2013-05-24 17:40:21] WARN  Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true

As you can see, the initial GET started at 17:39:35, and Rails is processing everything within at most hundreds of milliseconds (even 0 ms sometimes), but the timestamp between each event goes up by several seconds. The last event is at 17:40:19, which is 44 seconds after the initial GET. In practice, that means nothing shows up in my browser for over 40 seconds. I have no idea how to get Rails to speed up. I don't think it should take a simple tutorial app with 1 or 2 models this long to load, even in development mode.

Any ideas how to narrow down and solve this problem?

Note: the warnings about content-length should have nothing to do with the issue. They appeared when I downgraded to Ruby 1.9.3. I was using the latest Ruby (2.0.0), but thought that that was the source of the slow Rails performance so I switched to the recommended Ruby 1.9.3 and those warnings appeared for the first time. But Rails in dev mode is stil slow.

Thanks, Dave

Update: To help narrow down the issue, I disabled the asset pipeline and it does speed up noticeably. It's now 4-8 seconds instead of 20-40 However there are new errors, and I suppose I lose some functionality with the asset pipeline disabled. Is there a way to speed up the asset pipeline and keep it enabled?

ActionController::RoutingError (No route matches [GET] "/stylesheets/application.css"):
  actionpack (3.2.13) lib/action_dispatch/middleware/debug_exceptions.rb:21:in `call'
  actionpack (3.2.13) lib/action_dispatch/middleware/show_exceptions.rb:56:in `call'
  railties (3.2.13) lib/rails/rack/logger.rb:32:in `call_app'
  railties (3.2.13) lib/rails/rack/logger.rb:16:in `block in call'
  activesupport (3.2.13) lib/active_support/tagged_logging.rb:22:in `tagged'
  railties (3.2.13) lib/rails/rack/logger.rb:16:in `call'
  actionpack (3.2.13) lib/action_dispatch/middleware/request_id.rb:22:in `call'
  rack (1.4.5) lib/rack/methodoverride.rb:21:in `call'
  rack (1.4.5) lib/rack/runtime.rb:17:in `call'
  activesupport (3.2.13) lib/active_support/cache/strategy/local_cache.rb:72:in `call'
  rack (1.4.5) lib/rack/lock.rb:15:in `call'
  actionpack (3.2.13) lib/action_dispatch/middleware/static.rb:63:in `call'
  railties (3.2.13) lib/rails/engine.rb:479:in `call'
  railties (3.2.13) lib/rails/application.rb:223:in `call'
  rack (1.4.5) lib/rack/content_length.rb:14:in `call'
  railties (3.2.13) lib/rails/rack/log_tailer.rb:17:in `call'
  rack (1.4.5) lib/rack/handler/webrick.rb:59:in `service'
  /Users/ss/.rvm/rubies/ruby-1.9.3-p429/lib/ruby/1.9.1/webrick/httpserver.rb:138:in `service'
  /Users/ss/.rvm/rubies/ruby-1.9.3-p429/lib/ruby/1.9.1/webrick/httpserver.rb:94:in `run'
  /Users/ss/.rvm/rubies/ruby-1.9.3-p429/lib/ruby/1.9.1/webrick/server.rb:191:in `block in start_thread'

UPDATE: This post helped: Diagnosing the cause of slow view rendering

Basically, it turns out the delay was being caused by config.assets.debug = true inside of development.rb. I made it false and it seems to be faster.

The Rails guys say that enabling debug will slow down really complicated apps, but this was just a simple tutorial app with literally 1 model/controller/view. Anyways, I hope these performance gains last, but it does solve my immediate problem.

Answer 1

Copying the answer from the comments (and edited question body) in order to remove this question from the "Unanswered" filter:

I tried what they recommended in this post ( Diagnosing the cause of slow view rendering ), and it worked. Asset pipeline is enabled, and page loading goes from 20-40 seconds to like 1 second. much better at least.

...

Basically, it turns out the delay was being caused by config.assets.debug = true inside of development.rb. I made it false and it seems to be faster.

The Rails guys say that enabling debug will slow down really complicated apps, but this was just a simple tutorial app with literally 1 model/controller/view. Anyways, I hope these performance gains last, but it does solve my immediate problem.

~ answer per Dave Bowman

Answer 2

Also something important to take into consideration.

---

If you have caching setup but the credentials are not correct (or have been since updated as was the case for me) then Rails will try to connect to the server several times before giving up and processing the data manually.

For example in this block

@data = Rails.cache.fetch('all_market_data', expires_in: 1.hour) do
  Model.all.where(x: y).order('value ASC').each do |c|
    # functionality
    # proccessing
    # etc
  end
  @data
end

Rails will attempt to connect to whatever cache is configured in your development.rb config file.

Having failed that (approximately 20 seconds of trying) it will give up trying to connect to the cache itself and proccess the data itself (just as if the expiry on the cache had been met)

tldr: If you have caching setup, make sure that your credentials are up to date, and you can establish a connection.