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.
Rails works slower than any narrowly-targeted framework because Rails is a universal framework that contains many default functionalities that a developer doesn't have to write from scratch or install. For example, Rails has a default web server, called Puma.
Use Ruby GC Tuning GC, or garbage collection, is one more concept you need to get acquainted with to optimize the Ruby on Rails app. This is a method of managing the app's memory. By changing your Ruby GC settings you can speed up both unit tests and indeed, the whole application.
Go to your browser and open http://localhost:3000, you will see a basic Rails app running. You can also use the alias "s" to start the server: bin/rails s . The server can be run on a different port using the -p option. The default development environment can be changed using -e .
One of the things rails server does is that it loads all the dependencies/gems required by your Rails app, or at least sets them up to be auto-loaded later when they are needed. This is sometimes called "booting" or loading the "Rails environment".
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With