path: root/railties/doc/guides/bechmarking_and_profiling/basics.txt

== On The Road to Optimization == 
=== Looking at the log file in regards to optimization ===

 You actually have been gathering data for benchmarking throughout your development cycle. Your log files are not just for error detection they also contain very useful information on how speedy your action is behaving. 

.Regular Log Output
============================================================================
Processing MediaController#index (for 127.0.0.1 at 2008-07-17 21:30:21) [GET]

  Session ID: BAh7BiIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNo
SGFzaHsABjoKQHVzZWR7AA==--cb57dad9c5e4704f0e1eddb3d498fef544faaf46

  Parameters: {"action"=>"index", "controller"=>"media"}

  Product Columns (0.003187)   SHOW FIELDS FROM `products`
  Product Load (0.000597)   SELECT * FROM `products` WHERE (`products`.`name` = 'Escape Plane') LIMIT 1

Rendering template within layouts/standard

Rendering media/index
  Track Load (0.001507)   SELECT * FROM `tracks` WHERE (`tracks`.product_id = 1) 
  Track Columns (0.002280)   SHOW FIELDS FROM `tracks`

Rendered layouts/_header (0.00051)

*Completed in 0.04310 (23 reqs/sec) | Rendering: 0.00819 (19%) | DB: 0.00757 (17%) | 200 OK [http://localhost/media]*
============================================================================

What concerns us here is the last line of the action. 

Completed in 0.04310 (23 reqs/sec) gives us the amount of requests this specific action can handle.  0.04310 is the total amount of time the process to complete and 23 reqs/sec is an estimation from this. As we will see this number is not strictly valid since is a single instance of the process. But it does give you a general feel as to how the action is performing. 

Rendering: 0.00819 (19%)  is the amount in milliseconds and the percentage of total time needed to complete the action for rendering the view

DB: 0.00757 (17%) is the amount in milliseconds and the percentage of total time needed to complete the action for querying the database

Pretty easy right. But wait 17+19 equals 36. 36%! where  is the rest of the time going?  The rest of the time is being spent processing the controller. It is not shown but it is easy to calculate. Usually there is where most of your time ends on well functions actions. 

=== Why the Log File on it's Own is not Helpful ===

So why can't we just use this to test our rails application. Technically that could work, but would be very stressful and slow. You don't have time to view your log after every request to see if your code is running quickly. Also a request that runs 100 reqs/sec might simply be an outlier and really usually runs at 20 reqs/sec. It's simply not enough information to do everything we need it to do but it's a start. 

But there is something else we must consider.  

=== A Simple Question, a Complicated Answer ===

Is Completed in 0.04310 (23 reqs/sec) a good time. Seems like it doesn't it. 43 ms does not outrageous time for a dynamic page load. But is this a dynamic page load. Maybe it was all cached. In which case this is very slow. Or maybe I'm running on five year old equipment and this is actually blazing fast for my G3.  The truth is that we can't answer the question given the data. This is part of benchmarking. We need a baseline. Through comparative analysis of all your pages in your app, and an simple dynamic page for a control we can determine how fast your pages are actually running and if any of them need to be optimized. 

And now for something completely different a  short statistic lesson.