Есть похожие потоки о том, что Rails медленнее в режиме разработки, но ни одно из решений в этих потоках не имеет для меня никакого значения. Я попытался установить драгоценные камни, которые повышают производительность и сбрасывают файлы с конфигурационными файлами, но не имели успеха.
Я только начинаю с Rails, поэтому я запускаю приложение для запуска в руководстве "Getting Started with Rails", которое представляет собой небольшой блог. Я установил Ruby 1.9.3 и Rails 3.2.13, как рекомендовано. Я работаю на OS/X 10.7.5.
При загрузке стартовой страницы учебного приложения, буквально всего 1 строка текста и 1 ссылка, она занимает 20-40 секунд. Каждый последующий запрос на любую страницу занимает 20-40 секунд. Однако, когда я просматриваю журналы сервера, ничего, что делает Rails, похоже, занимает много времени. Это время между событиями в журналах, которые занимают все время. Будучи новичком в Rails, я понятия не имею, как отлаживать это.
Например:
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
Как вы можете видеть, начальное GET началось в 17:39:35, а Rails обрабатывает все в течение не более сотни миллисекунд (иногда даже 0 мс), но временная метка между каждым событием увеличивается на несколько секунд. Последнее событие в 17:40:19, что составляет 44 секунды после первоначального GET. На практике это означает, что ничего не отображается в моем браузере более 40 секунд. Я понятия не имею, как заставить Rails ускоряться. Я не думаю, что это должно быть простым учебным приложением с 1 или 2 моделями, которые так долго загружаются, даже в режиме разработки.
Любые идеи, как сузить и решить эту проблему?
Примечание. Предупреждения о длине содержимого не должны иметь никакого отношения к проблеме. Они появились, когда я понизился до Ruby 1.9.3. Я использовал последний Ruby (2.0.0), но думал, что это был источник медленной производительности Rails, поэтому я переключился на рекомендуемый Ruby 1.9.3, и эти предупреждения появились впервые. Но Rails в режиме dev медленнее.
Спасибо, Dave
Обновление: Чтобы уменьшить проблему, я отключил конвейер активов, и он заметно ускорился. Это сейчас 4-8 секунд вместо 20-40. Однако появляются новые ошибки, и я полагаю, что я потерял некоторые функциональные возможности с отключенным контуром. Есть ли способ ускорить работу с конвейером и поддерживать его?
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: Этот пост помог: Диагностика причины медленного рендеринга просмотра
В принципе, оказывается, что задержка вызвана config.assets.debug = true внутри development.rb. Я сделал это ложным и, похоже, быстрее.
Ребята из Rails говорят, что включение debug замедлит действительно сложные приложения, но это было просто простое учебное приложение с буквально 1 моделью/контроллером/представлением. В любом случае, я надеюсь, что эти улучшения производительности будут продолжаться, но это решает мою непосредственную проблему.
