rails 2.2.3 → 2.3.2

data/doc/guides/source/benchmarking_and_profiling/index.txt

@@ -1,242 +0,0 @@
-Benchmarking and Profiling Rails
-================================
-
-This guide covers the benchmarking and profiling tactics/tools of Rails and Ruby in general. By referring to this guide, you will be able to:
-
-* Understand the various types of benchmarking and profiling metrics
-* Generate performance/benchmarking tests
-* Use GC patched Ruby binary to measure memory usage and object allocation
-* Understand the information provided by Rails inside the log files
-* Learn about various tools facilitating benchmarking and profiling
-
-== Why Benchmark and Profile ?
-
-Benchmarking and Profiling is an integral part of the development cycle. It is very important that you don't make your end users wait for too long before the page is completely loaded. Ensuring a plesant browsing experience to the end users and cutting cost of unnecessary hardwares is important for any web application.
-
-=== What is the difference between benchmarking and profiling ? ===
-
-Benchmarking is the process of finding out if a piece of code is slow or not. Whereas profiling is the process of finding out what exactly is slowing down that piece of code.
-
-== Using and understanding the log files ==
-
-Rails logs files containt basic but very useful information about the time taken to serve every request. A typical log entry looks something like :
-
-[source, ruby]
-----------------------------------------------------------------------------
-Processing ItemsController#index (for 127.0.0.1 at 2008-10-17 00:08:18) [GET]
-  Session ID: BAh7BiIKZmxhc2hJQzonQWN0aHsABjoKQHVzZWR7AA==--83cff4fe0a897074a65335
-  Parameters: {"action"=>"index", "controller"=>"items"}
-Rendering template within layouts/items
-Rendering items/index
-Completed in 5ms (View: 2, DB: 0) | 200 OK [http://localhost/items]
-----------------------------------------------------------------------------
-
-For this section, we're only interested in the last line from that log entry:
-
-[source, ruby]
-----------------------------------------------------------------------------
-Completed in 5ms (View: 2, DB: 0) | 200 OK [http://localhost/items]
-----------------------------------------------------------------------------
-
-This data is fairly straight forward to understand. Rails uses millisecond(ms) as the metric to measures the time taken. The complete request spent 5 ms inside Rails, out of which 2 ms were spent rendering views and none was spent communication with the database. It's safe to assume that the remaining 3 ms were spent inside the controller.
-
-== Helper methods ==
-
-Rails provides various helper methods inside Active Record, Action Controller and Action View to measure the time taken by a specific code. The method is called +benchmark()+ in all three components.
-
-[source, ruby]
-----------------------------------------------------------------------------
-Project.benchmark("Creating project") do
-  project = Project.create("name" => "stuff")
-  project.create_manager("name" => "David")
-  project.milestones << Milestone.find(:all)
-end
-----------------------------------------------------------------------------
-
-The above code benchmarks the multiple statments enclosed inside +Project.benchmark("Creating project") do..end+ block and prints the results inside log files. The statement inside log files will look like:
-
-[source, ruby]
-----------------------------------------------------------------------------
-Creating projectem (185.3ms)
-----------------------------------------------------------------------------
-
-Please refer to http://api.rubyonrails.com/classes/ActiveRecord/Base.html#M001336[API docs] for optional options to +benchmark()+
-
-Similarly, you could use this helper method inside http://api.rubyonrails.com/classes/ActionController/Benchmarking/ClassMethods.html#M000715[controllers] ( Note that it's a class method here ):
-
-[source, ruby]
-----------------------------------------------------------------------------
-def process_projects
-  self.class.benchmark("Processing projects") do
-    Project.process(params[:project_ids])
-    Project.update_cached_projects
-  end
-end
-----------------------------------------------------------------------------
-
-and http://api.rubyonrails.com/classes/ActionController/Benchmarking/ClassMethods.html#M000715[views]:
-
-[source, ruby]
-----------------------------------------------------------------------------
-<% benchmark("Showing projects partial") do %>
-  <%= render :partial => @projects %>
-<% end %>
-----------------------------------------------------------------------------
-
-== Performance Test Cases ==
-
-Rails provides a very easy to write performance test cases, which look just like the regular integration tests.
-
-If you have a look at +test/performance/browsing_test.rb+ in a newly created Rails application:
-
-[source, ruby]
-----------------------------------------------------------------------------
-require 'test_helper'
-require 'performance_test_help'
-
-# Profiling results for each test method are written to tmp/performance.
-class BrowsingTest < ActionController::PerformanceTest
-  def test_homepage
-    get '/'
-  end
-end
-----------------------------------------------------------------------------
-
-This is an automatically generated example performance test file, for testing performance of homepage('/') of the application.
-
-=== Modes ===
-
-==== Benchmarking ====
-==== Profiling ====
-
-=== Metrics ===
-
-==== Process Time ====
-
-CPU Cycles.
-
-==== Memory ====
-
-Memory taken.
-
-==== Objects ====
-
-Objects allocated.
-
-==== GC Runs ====
-
-Number of times the Ruby GC was run.
-
-==== GC Time ====
-
-Time spent running the Ruby GC.
-
-=== Preparing Ruby and Ruby-prof ===
-
-Before we go ahead, Rails performance testing requires you to build a special Ruby binary with some super powers - GC patch for measuring GC Runs/Time. This process is very straight forward. If you've never compiled a Ruby binary before, you can follow the following steps to build a ruby binary inside your home directory:
-
-==== Compile ====
-
-[source, shell]
-----------------------------------------------------------------------------
-[lifo@null ~]$ mkdir rubygc
-[lifo@null ~]$ wget ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.6-p111.tar.gz
-[lifo@null ~]$ tar -xzvf ruby-1.8.6-p111.tar.gz
-[lifo@null ~]$ cd ruby-1.8.6-p111
-[lifo@null ruby-1.8.6-p111]$ curl http://rubyforge.org/tracker/download.php/1814/7062/17676/3291/ruby186gc.patch | patch -p0
-[lifo@null ruby-1.8.6-p111]$ ./configure --prefix=/Users/lifo/rubygc
-[lifo@null ruby-1.8.6-p111]$ make && make install
-----------------------------------------------------------------------------
-
-==== Prepare aliases ====
-
-Add the following lines in your ~/.profile for convenience:
-
-----------------------------------------------------------------------------
-alias gcruby='/Users/lifo/rubygc/bin/ruby'
-alias gcrake='/Users/lifo/rubygc/bin/rake'
-alias gcgem='/Users/lifo/rubygc/bin/gem'
-alias gcirb='/Users/lifo/rubygc/bin/irb'
-alias gcrails='/Users/lifo/rubygc/bin/rails'
-----------------------------------------------------------------------------
-
-==== Install rubygems and some basic gems ====
-
-----------------------------------------------------------------------------
-[lifo@null ~]$ wget http://rubyforge.org/frs/download.php/38646/rubygems-1.2.0.tgz
-[lifo@null ~]$ tar -xzvf rubygems-1.2.0.tgz
-[lifo@null ~]$ cd rubygems-1.2.0
-[lifo@null rubygems-1.2.0]$ gcruby setup.rb
-[lifo@null rubygems-1.2.0]$ cd ~
-[lifo@null ~]$ gcgem install rake
-[lifo@null ~]$ gcgem install rails
-----------------------------------------------------------------------------
-
-==== Install MySQL gem ====
-
-----------------------------------------------------------------------------
-[lifo@null ~]$ gcgem install mysql
-----------------------------------------------------------------------------
-
-If this fails, you can try to install it manually:
-
-----------------------------------------------------------------------------
-[lifo@null ~]$ cd /Users/lifo/rubygc/lib/ruby/gems/1.8/gems/mysql-2.7/
-[lifo@null mysql-2.7]$ gcruby extconf.rb --with-mysql-config
-[lifo@null mysql-2.7]$ make && make install
-----------------------------------------------------------------------------
-
-=== Installing Jeremy Kemper's ruby-prof ===
-
-We also need to install Jeremy's ruby-prof gem using our newly built ruby:
-
-[source, shell]
-----------------------------------------------------------------------------
-[lifo@null ~]$ git clone git://github.com/jeremy/ruby-prof.git
-[lifo@null ~]$ cd ruby-prof/
-[lifo@null ruby-prof (master)]$ gcrake gem
-[lifo@null ruby-prof (master)]$ gcgem install pkg/ruby-prof-0.6.1.gem
-----------------------------------------------------------------------------
-
-=== Generating performance test ===
-
-Rails provides a simple generator for creating new performance tests:
-
-[source, shell]
-----------------------------------------------------------------------------
-[lifo@null application (master)]$ script/generate performance_test homepage
-----------------------------------------------------------------------------
-
-This will generate +test/performance/homepage_test.rb+:
-
-[source, ruby]
-----------------------------------------------------------------------------
-require 'test_helper'
-require 'performance_test_help'
-
-class HomepageTest < ActionController::PerformanceTest
-  # Replace this with your real tests.
-  def test_homepage
-    get '/'
-  end
-end
-----------------------------------------------------------------------------
-
-Which you can modify to suit your needs.
-
-=== Running tests ===
-
-include::rubyprof.txt[]
-
-include::digging_deeper.txt[]
-
-include::gameplan.txt[]
-
-include::appendix.txt[]
-
-== Changelog ==
-
-http://rails.lighthouseapp.com/projects/16213-rails-guides/tickets/4[Lighthouse ticket]
-
-* October 17, 2008: First revision by Pratik
-* September 6, 2008: Initial version by Matthew Bergman <MzbPhoto@gmail.com>

data/doc/guides/source/benchmarking_and_profiling/rubyprof.txt

@@ -1,179 +0,0 @@
-== Understanding Performance Tests Outputs ==
-
-=== Our First Performance Test ===
-
-So how do we profile a request. 
-
-One of the things that is important to us is how long it takes to render the home page - so let's make a request to the home page. Once the request is complete, the results will be outputted in the terminal. 
-
-In the terminal run
-
-[source, ruby]
-----------------------------------------------------------------------------
-[User profiling_tester]$ gcruby tests/performance/homepage.rb
-----------------------------------------------------------------------------
-
-After the tests runs for a few seconds you should see something like this. 
-
-----------------------------------------------------------------------------
-HomepageTest#test_homepage (19 ms warmup)
-        process_time: 26 ms
-              memory: 298.79 KB
-             objects: 1917
-
-Finished in 2.207428 seconds.
-----------------------------------------------------------------------------
-
-Simple but efficient. 
-
-* Process Time refers to amount of time necessary to complete the action. 
-* memory is the amount of information loaded into memory
-* object ??? #TODO find a good definition. Is it the amount of objects put into a ruby heap for this process?
-
-In addition we also gain three types of itemized log files for each of these outputs. They can be found in your tmp directory of your application.
-
-*The Three types are*
-
-* Flat File - A simple text file with the data laid out in a grid
-* Graphical File - A html colored coded version of the simple text file with hyperlinks between the various methods. Most useful is the bolding of the main processes for each portion of the action. 
-* Tree File - A file output that can be use in conjunction with KCachegrind to visualize the process
-
-NOTE: KCachegrind is Linux only. For Mac this means you have to do a full KDE install to have it working in your OS. Which is over 3 gigs in size. For windows there is clone called wincachegrind but it is no longer actively being developed.  
-
-Below are examples for Flat Files and Graphical Files
-
-=== Flat Files ===
-
-.Flat File Output Processing Time
-============================================================================
-Thread ID: 2279160
-Total: 0.026097
-
- %self     total     self     wait    child    calls  name
-  6.41      0.06     0.04     0.00     0.02      571  Kernel#===
-  3.17      0.00     0.00     0.00     0.00      172  Hash#[]
-  2.42      0.00     0.00     0.00     0.00       13  MonitorMixin#mon_exit
-  2.05      0.00     0.00     0.00     0.00       15  Array#each
-  1.56      0.00     0.00     0.00     0.00        6  Logger#add
-  1.55      0.00     0.00     0.00     0.00       13  MonitorMixin#mon_enter
-  1.36      0.03     0.00     0.00     0.03        1  ActionController::Integration::Session#process
-  1.31      0.00     0.00     0.00     0.00       13  MonitorMixin#mon_release
-  1.15      0.00     0.00     0.00     0.00        8  MonitorMixin#synchronize-1
-  1.09      0.00     0.00     0.00     0.00       23  Class#new
-  1.03      0.01     0.00     0.00     0.01        5  MonitorMixin#synchronize
-  0.89      0.00     0.00     0.00     0.00       74  Hash#default
-  0.89      0.00     0.00     0.00     0.00        6  Hodel3000CompliantLogger#format_message
-  0.80      0.00     0.00     0.00     0.00        9  c
-  0.80      0.00     0.00     0.00     0.00       11  ActiveRecord::ConnectionAdapters::ConnectionHandler#retrieve_connection_pool
-  0.79      0.01     0.00     0.00     0.01        1  ActionController::Benchmarking#perform_action_without_rescue
-  0.18      0.00     0.00     0.00     0.00       17  <Class::Object>#allocate
-============================================================================  
-
-So what do these columns tell us:
-
-	* %self - The percentage of time spent processing the method. This is derived from self_time/total_time
-	* total - The time spent in this method and its children.
-	* self - The time spent in this method.
-	* wait - Time processed was queued
-	* child - The time spent in this method's children.
-	* calls - The number of times this method was called.
-    *  name - The name of the method.
-
-Name can be displayed three seperate ways:
-	* #toplevel - The root method that calls all other methods
-	* MyObject#method - Example Hash#each, The class Hash is calling the method each
-	* <Object:MyObject>#test - The <> characters indicate a singleton method on a singleton class. Example <Class::Object>#allocate
-	
-Methods are sorted based on %self. Hence the ones taking the most time and resources will be at the top.
-
-So for Array#each which is calling each on the class array. We find that it processing time is 2% of the total and was called 15 times. The rest of the information is 0.00 because the process is so fast it isn't recording times less then 100 ms. 
-
-
-.Flat File Memory Output
-============================================================================
-Thread ID: 2279160
-Total: 509.724609
-
- %self     total     self     wait    child    calls  name
-  4.62     23.57    23.57     0.00     0.00       34  String#split
-  3.95     57.66    20.13     0.00    37.53        3  <Module::YAML>#quick_emit
-  2.82     23.70    14.35     0.00     9.34        2  <Module::YAML>#quick_emit-1
-  1.37     35.87     6.96     0.00    28.91        1  ActionView::Helpers::FormTagHelper#form_tag
-  1.35      7.69     6.88     0.00     0.81        1  ActionController::HttpAuthentication::Basic::ControllerMethods#authenticate_with_http_basic
-  1.06      6.09     5.42     0.00     0.67       90  String#gsub
-  1.01      5.13     5.13     0.00     0.00       27  Array#-
-============================================================================
-
-Very similar to the processing time format. The main difference here is that instead of calculating time we are now concerned with the amount of KB put into memory *(or is it strictly into the heap) can I get clarification on this minor point?* 
-
-So for <Module::YAML>#quick_emit which is  singleton method on the class YAML it uses 57.66 KB in total, 23.57 through its own actions, 6.69 from actions it calls itself and that it was called twice.
-
-.Flat File Objects 
-============================================================================
-Thread ID: 2279160
-Total: 6537.000000
-
- %self     total     self     wait    child    calls  name
- 15.16   1096.00   991.00     0.00   105.00       66  Hash#each
-  5.25    343.00   343.00     0.00     0.00        4  Mysql::Result#each_hash
-  4.74   2203.00   310.00     0.00  1893.00       42  Array#each
-  3.75   4529.00   245.00     0.00  4284.00        1  ActionView::Base::CompiledTemplates#_run_erb_47app47views47layouts47application46html46erb
-  2.00    136.00   131.00     0.00     5.00       90  String#gsub
-  1.73    113.00   113.00     0.00     0.00       34  String#split
-  1.44    111.00    94.00     0.00    17.00       31  Array#each-1
-============================================================================
-
-
- #TODO Find correct terminology for how to describe what this is exactly profiling as in are there really 2203 array objects or 2203 pointers to array objects?. 
-
-=== Graph Files ===
-
-While the information gleamed from flat files is very useful we still don't know which processes each method is calling. We only know how many. This is not true for a graph file. Below is a text representation of a graph file. The actual graph file is an html entity and an example of which can be found link:examples/graph.html[Here] 
-
-#TODO (Handily the graph file has links both between it many processes and to the files that actually contain them for debugging. 
- )
-
-.Graph File
-============================================================================
-Thread ID: 21277412
-
-  %total   %self     total      self    children               calls   Name
-/____________________________________________________________________________/
-100.00%   0.00%      8.77      0.00      8.77                   1     #toplevel*
-                     8.77      0.00      8.77                 1/1     Object#run_primes
-/____________________________________________________________________________/
-                     8.77      0.00      8.77                 1/1     #toplevel
-100.00%   0.00%      8.77      0.00      8.77                   1     Object#run_primes*
-                     0.02      0.00      0.02                 1/1     Object#make_random_array
-                     2.09      0.00      2.09                 1/1     Object#find_largest
-                     6.66      0.00      6.66                 1/1     Object#find_primes
-/____________________________________________________________________________/
-                     0.02      0.02      0.00                 1/1     Object#make_random_array
-0.18%     0.18%      0.02      0.02      0.00                   1     Array#each_index
-                     0.00      0.00      0.00             500/500     Kernel.rand
-                     0.00      0.00      0.00             500/501     Array#[]=
-/____________________________________________________________________________/
-============================================================================
-
-As you can see the calls have been separated into slices, no longer is the order determined by process time but instead from hierarchy. Each slice profiles a primary entry, with the primary entry's parents being shown above itself and it's children found below. A primary entry can be ascertained by it having values in the %total and %self columns. Here the main entry here have been bolded for connivence. 
-
-So if we look at the last slice. The primary entry would be Array#each_index. It takes 0.18% of the total process time and it is only called once. It is called from Object#make_random_array which is only called once. It's children are Kernal.rand which is called by it all 500 its times that it was call in this action and Arry#[]= which was called 500 times by Array#each_index and once by some other entry. 
-
-=== Tree Files ===
-
-It's pointless trying to represent a tree file textually so here's a few pretty pictures of it's usefulness 
-
-.KCachegrind Graph
-[caption="KCachegrind graph"] 
-image:images/kgraph.png[Graph created by KCachegrind] 
-
-.KCachegrind List
-[caption="KCachegrind List"] 
-image:images/klist.png[List created by KCachegrind]
-
-#TODO Add a bit more information to this. 
-
-== Getting to the Point of all of this ==
-
-Now I know all of this is a bit dry and academic. But it's a very powerful tool when you know how to leverage it properly. Which we are going to take a look at in our next section
-

data/doc/guides/source/benchmarking_and_profiling/statistics.txt

@@ -1,57 +0,0 @@
-== A Lession In Statistics ==
-
-#TODO COMPRESS DOWN INTO A PARAGRAPH AND A HALF 
-maybe I'll just combine with the methodology portion as an appendix. 
-
-Adapted from a blog Article by Zed Shaw. His rant is funnier but will take longer to read. <br /> http://www.zedshaw.com/rants/programmer_stats.html[Programmers Need To Learn Statistics Or I Will Kill Them All]
-
-=== Why Learn Statistics ===
-
-Statistics is a hard discipline. One can study it for years without fully grasping all the complexities. But its a necessary evil for coders of every level to at least know the basics. You can't optimize without it, and if you use it wrong, you'll just waste your time and the rest of your team's.
-
-=== Power-of-Ten Syndrome ===
-
-If you done any benchmarking you have probably heard
-“All you need to do is run that test [insert power-of-ten] times and then do an average.” 
-
-For new developers this whole power of ten comes about because we need enough data to minimize the results being contaminated by outliers. If you loaded a page five times with three of those times being around 75ms and twice 250ms you have no way of knowing the real average processing time for you page. But if we take a 1000 times and 950 are 75ms and 50 are 250ms we have a much clearer picture of the situation. 
-
-But this still begs the question of how you determine that 1000 is the correct number of iterations to improve the power of the experiment? (Power in this context basically means the chance that your experiment is right.)
-
-The first thing that needs to be determined is how you are performing the samplings? 1000 iterations run in a massive sequential row? A set of 10 runs with 100 each? The statistics are different depending on which you do, but the 10 runs of 100 each would be a better approach. This lets you compare sample means and figure out if your repeated runs have any bias. More simply put, this allows you to see if you have a many or few outliers that might be poisoning your averages. 
-
-Another consideration is if a 1000 transactions is enough to get the process into a steady state after the ramp-up period? If you are benchmarking a long running process that stabilizes only after a warm-up time you must take that into consideration. 
-
-Also remember getting an average is not an end goal in itself. In fact in some cases they tell you almost nothing. 
-
-=== Don't Just Use Averages! ===
-
-One cannot simply say my website “[insert power-of-ten] requests per second”. This is due to it being an Average. Without some form of range or variance error analysis it's a useless number.  Two averages can be the same, but hide massive differences in behavior. Without a standard deviation it’s not possible to figure out if the two might even be close. 
-
-Two averages can be the same say 30 requests a second and yet have a completely different standard deviation. Say the first sample has +-3 and the second is +-30
-
-Stability is vastly different for these two samples If this were a web server performance run I’d say the second server has a major reliability problem. No, it’s not going to crash, but it’s performance response is so erratic that you’d never know how long a request would take. Even though the two servers perform the same on average, users will think the second one is slower because of how it seems to randomly perform.
-
-Another big thing to take into consideration when benchmarking and profiling is Confounding
-
-=== Confounding ===
-
-The idea of confounding is pretty simple: If you want to measure something, then don’t measure anything else.  
-
-#TODO add more information in how to avoid confounding. 
-
-* Your testing system and your production system must be separate. You can't profile on the same system because you are using resources to run the test that your server should be using to serve the requests. 
-
-And one more thing. 
-
-=== Define what you are Measuring ===
-
-Before you can measure something you really need to lay down a very concrete definition of what you’re measuring. You should also try to measure the simplest thing you can and try to avoid confounding. 
-
-The most important thing to determine though is how much data you can actually send to your application through it's pipe. 
-
-=== Back to Business ===
-
-Now I know this was all a bit boring, but these fundamentals a necessary for understanding what we are actually doing here. Now onto the actual code and rails processes. 
-
-