On Tue, Apr 8, 2008 at 9:46 AM, Jonathan Rochkind <[log in to unmask]> wrote:

>  I'm not really sure how to start.  The fact that I really need to
>  include examination of things that happen during view rendering (helper
>  methods, but possibly also db access that might unwise be in the view
>  code itself) makes me especially confused. Most of the stuff I find on
>  the web on this topic is about determining which actions take up most of
>  your apps time, or determining how many concurrent users your app can
>  handle. Neither of those is what I need to do! I need to get into the
>  guts of an already identified action, and figure out how to speed it up.

First thing, I'd look at the Rails log. It'll tell you how much time
you're spending in database and rendering, at least -- though it won't
report on 'business logic time', which can be quite large, especially
if you're getting lots of ActiveRecord objects (hint: don't do that).

If that suggests that your queries are slow, the Rails Query Analyzer
plugin will show you *a lot* of what's happening, query-wise. It needs
MySQL -- but the standard development log will at least tell you every
query run (and how long those queries take...?)... so you can use your
own database's query analyzer and see what they're up to.

A few very loose performance rules of thumb:

* Making AR objects is expensive. Cutting down the number of objects
in a collection with more selective SQL is almost always better than
filtering with ruby.

* And if your queries are slow... index, index, index. Try rewriting
with subqueries. Or without subqueries. The MySQL query optimizer can
be a fickle beast.

* Make development as close to production as is reasonable. Don't
assume that things that are fast (or slow) in sqlite are fast in
mysql, or in postgres.

* Put off getting collections as long as you can (for example, don't
do @articles = @person.articles in your controller; just use
@person.articles in your view). This will make fragment caching way,
way easier.

* If you need to iterate over a lot of AR objects, it can be a lot
better to do it in small batches -- AR doesn't support cursors and
will (un)happily load 1,000,000 objects into memory.

Cheers,
-Nate