views:

1002

answers:

3

I am working on an "optimization" on my application and I am trying to understand the output that rails (version 2.2.2) gives at the end of the render.

Here is the "old" way:

Rendered user/_old_log (25.7ms)
Completed in 466ms (View: 195, DB: 8) | 200 OK

And the "new" way:

Rendered user/_new_log (48.6ms)
Completed in 337ms (View: 192, DB: 33) | 200 OK

These queries were exactly the same, the difference is the old way is parsing log files while the new way is querying the database log table.

The actual speed of the page is not the issue (the user understands that this is a slow request) ... but I would like the page to respond as quickly as possible even though it is a "slow" page.

So, my question is, what do the numbers represent/mean? In other words, which way was the faster method and why?

A: 

Your new way is spending less time overall but more time rendering the template.

rabble
Can you breakdown (or point me to a write up) of how to interpret these on my own?
salt.racer
+5  A: 

This:

Rendered user/_old_log (25.7ms)

is the time to render just the _old_log partial template, and comes from renderable_partial.rb:19 which ends up calling benchmarking.rb:27

This:

Completed in 466ms

Is the total time for the entire request and comes from benchmarking.rb:72

These:

(View: 195, DB: 8) | 200 OK

are the total times for rendering the entire view (partials & everything) and all database requests, respectively, and come from benchmarking.rb:74-84

Jordan Brough
+1  A: 

Jordan's answer is correct. To paraphrase, the first number is the time the page took to load. The second is how long the view took to generate. The last number is how long it took for your database to handle all queries you sent to it.

You can also get an estimation of how long your Controller and Model code took by subtracting the last two numbers from the first number, but a better way would be to use the Benchmark.measure method (http://www.ruby-doc.org/stdlib/libdoc/benchmark/rdoc/classes/Benchmark.html).

Your new way appears to have improved because code in the Controller/Model completes faster.

Gdeglin