Diagnosing the cause of slow view rendering

Question

I\'m not sure when this started, but something unusual is happening in my app (run locally on a development machine). Suddenly I am seeing messages like:

Sta         


        

Answer 1

Ok, I figured it out (at long last). Without changing any of my actual assets I am now seeing this is development:

Started GET "/" for 127.0.0.1 at 2013-03-11 23:14:33 +1300
Processing by PagesController#home as HTML
Rendered pages/home.html.erb within layouts/application (1.3ms)

It turns out the delay was being caused by config.assets.debug = true inside of development.rb. Setting this to false resolves the problem.

Looks like the Rails core team debated turning this off by default, but decided against the idea. In the future I'd love to see them put something in the comment section of development.rb to tip off users of the potential for significant delays.

May I suggest the following:

# Expands the lines which load the assets 
# May cause significant delays in view rendering

Great, they heard me muttering and updated rails!

Answer 2

The same issue has appeared for me in rails 4.1+. Abram's answer is only partially complete.

You can leave config.assets.debug = true but should disable new assets verification feature

# Adds additional error checking when serving assets at runtime.
# Checks for improperly declared sprockets dependencies.
# Raises helpful error messages.
config.assets.raise_runtime_errors = false

Solution with config.assets.debug disabled only works because it compiles assets once and assets are verified once. Assets verification is where the most of the time is spent.

Answer 3

Take a look at NewRelic.com - it costs, but the free trial will allow you to totally dissect your application and work out where any bottlenecks are.

Aside from New Relic run through the usual checks, e.g. when did it start? What have you changed recently? Have you upgraded Rails and/or any gems? Check out and run a few previous versions from your source control and try and work out specifically which commit caused the issue.

Does the issue happen with all browsers? Try firing up the Chrome timeline viewer and you'll be able to see if the browser is getting stuck up on a particular piece of JavaScript.

Also try switching your local dev web server to thin, does the issue persist?

Good luck!

Answer 4

If you're coming from rails 3.2.13 note that a bunch of people have experienced this issue and reverting to 3.2.12 seems to resolve it. You can find more info here on github.

In my case disabling config.assets.debug sped things up a little, but reverting to 3.2.12 dropped request time from around 4 seconds to around 250ms.

Answer 5

Are you on OSX and serving via .local?

If so, gonna throw the post I found in my comments as a solution:
Subdomain constraint (Rails 3) makes local server (thin) SO SLOW