I'm having some trouble with my Rails app being very slow on my staging server. What is most confusing is that the final line of the log output for each request.
It seems the View and Database times aren't even close to the entire render time. On one page it is as bad as ~1000ms for Completion, ~450ms for the View and ~20ms Database.
Where does the rest of the time required to render the page come from?
I recommend using New Relic's RPM service. It has a free version, but the Bronze service ($40 a month) is wonderful and further helps track down these issues.
When things are mysterious.... profilers are your friend!
a profiler will draw up statistics of which methods are being called the most and how long is being spent in each method call.
ruby-prof does the trick for me when I'm in RubyLand, and it will produce a nice call-graph (in html format if you want), that makes it nice and easy to see which methods are slowing up your request.
I was just about to revisit this question with the same answer, so I'll just piggyback. Here is a very small ruby-prof snippet from one view rendering. It's amazing how much stuff goes on under the hood.
Besides rendering and database time, some time is spent in your controller code and the Rails framework. This can be really slow if too few resources are assigned to your staging server. You should not however that the durations in the log are not always perfect, especially the database duration.
What does your apache log say? It will definitely have different numbers to show the time required to serve the request.
Apache sends requests to rails and rails works on it and that is what you see in your production logs.
All the HTML still has to be rendered on your browser (heavy CSS, images, js etc). Try using firefox extension httpwatch to know rendering time of UI elements and it should add up.
As suggested earlier, NewRelic should give you decent breakup of time spent in various activities (M V C)
I've found a large proportion of the render time can be spent on Rails creating and preparing Active Record objects. After the query and before the view. Depending on how many records are returned from a 'find', for example.