title: Rails development server is slow and takes a long time to load a simple page
body: <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>For example:</p>
  
  <pre><code>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"=&gt;"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
  </code></pre>
  
  <p>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.</p>
  
  <p>Any ideas how to narrow down and solve this problem?</p>
  
  <p>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.</p>
  
  <p>Thanks,
  Dave</p>
  
  <p>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?</p>
  
  <pre><code>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'
  </code></pre>
  
  <p>UPDATE:
  This post helped: <a href="https://stackoverflow.com/questions/15317048/diagnosing-the-cause-of-slow-view-rendering">Diagnosing the cause of slow view rendering</a></p>
  
  <p>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.</p>
  
  <p>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.</p>