One of my current projects involves significantly improving the search function in a Rails application, a thorny problem that led me to come up with the method to quiet down the Rails logger in my SQL log silencer. It turns out, that wasn’t enough. I have expanded quite a bit on that idea by folding in some useful debugging aids from other developers, making them more useful, and adding a SQL query “hit list” after each request completes. I’m releasing it as the sql_logging plug-in.
Installation is the usual (on one line):
$ script/plugin install \
http://svn.lightyearsoftware.com/svn/plugins/sql_logging
I have set up a forum for discussion and support of the plug-in.
So, what does this give you?
Out of the box, you get these new things:
- A count of the number of rows returned and a rough count of bytes for each SELECT query
- A summary at the end of the request of the total number of queries, bytes returned and SQL executions
- Each SQL execution includes a clean-up backtrace to show you exactly what part of your code triggered the query
- A summary at the end of the request showing a “top 10” list of queries
The last one is particular useful. Queries are grouped by their backtrace, and then sorted by either number of executions, rows returned or bytes returned. This provides an excellent way to target your performance optimization work.
When sorted by executions, you very quickly see where the same code is triggering a query over and over, and can spend your optimization time trying to reduce this by adding the model to an earlier query (via :include) or by getting more rows at a time by batching up loads (WHERE id IN (...)). Here’s a sample:
Completed in 13.01586 (0 reqs/sec) | Rendering: 2.69928 (20%) | DB: 8.68216 (66%), 154 selects, 1728.1 KB, 166 execs
Top 10 SQL executions:
Executed 95 times, returning 180 rows (230.5 KB):
app/models/merge_keyword.rb:34:in `get_merges_by_keyword'
app/models/merge_keyword.rb:30:in `each'
app/models/merge_keyword.rb:30:in `get_merges_by_keyword'
app/models/merge.rb:107:in `search'
app/models/merge.rb:105:in `each'
app/models/merge.rb:105:in `search'
app/controllers/search_controller.rb:98:in `results'
Executed 22 times, returning 30 rows (1.3 KB):
app/models/merge.rb:80:in `attribute'
app/views/merges/_result_line.rhtml:2:in `_run_rhtml_47app47views47merges47_result_line46rhtml'
app/views/search/results.rhtml:172:in `_run_rhtml_47app47views47search47results46rhtml'
app/views/search/results.rhtml:170:in `each'
app/views/search/results.rhtml:170:in `each_with_index'
app/views/search/results.rhtml:170:in `_run_rhtml_47app47views47search47results46rhtml'
Executed 20 times, returning 30 rows (1.2 KB):
app/models/merge.rb:80:in `attribute'
app/helpers/application_helper.rb:40:in `merge_detail_link'
app/views/merges/_result_line.rhtml:26:in `_run_rhtml_47app47views47merges47_result_line46rhtml'
app/views/search/results.rhtml:172:in `_run_rhtml_47app47views47search47results46rhtml'
app/views/search/results.rhtml:170:in `each'
app/views/search/results.rhtml:170:in `each_with_index'
app/views/search/results.rhtml:170:in `_run_rhtml_47app47views47search47results46rhtml'
By sorting by rows or bytes returned, you may be able to determine that you need to let the database do more of the filtering work. It may be inefficient to have the database return a pile of rows to your application, only to discard a bunch of them.
The silencer from my previous post is in there, too, along with a new silencer that quiets only the backtrace for the duration of the block:
silence_sql do
# ...
end
silence_sql_backtrace do
# ...
end |
silence_sql do
# ...
end
silence_sql_backtrace do
# ...
end
I must give a big hat tip to Adam Doppelt and Nathaniel Talbott. Adam’s SQL logging enhancements formed the basis for the logging enhancements here. I made them a little more generic so they worked with both MySQL and PostgreSQL, as well as tracking executions for things that don’t return data. Nathaniel’s QueryTrace plug-in has been around for a while, and I originally tried making this new plug-in simply work with it, but in the end decided to fold the functionality in so the “top 10” list didn’t duplicate the backtrace cleaning code. I also added a regexp to the cleaner so it excludes the plug-in’s code from the backtrace.
There are a few more goodies in the plug-in, so look at the README for more details.
Update: I fixed a few bugs and added a feature. The plug-in now ignores queries whose name ends with ” Column”. These are internal Rails queries and their inclusion skewed the results.
The new feature tracks the execution time of SQL, and lets you sort the top-10 list by either total time for all instances of the SQL or the median execution time. Total time is also now the default sorting method, as this is probably the best way to attack SQL optimization: whatever is taking up the biggest percentage of your time in the database is a good place to start.
Update 2: The plug-in works on Rails 2.0.2 now.
