[LRUG] Fwd: Recommendations for Ruby & Rails optimisation resources
Jonathan del Strother
maillist at steelskies.com
Mon Nov 26 06:38:13 PST 2012
On 26 November 2012 14:04, Simon Coffey <simon at tribesports.com> wrote:
> On 26 November 2012 13:14, Jonathon Horsman <jonathon at arctickiwi.com> wrote:
>>
>> Thanks for all the suggestions.
>>
>> I've added the new relic gem and looked at the results, which seem a bit
>> light on details unless I'm missing something.
>>
>
> The free account gives you very little info from production - you can
> inspect a full trace breakdown in development mode, though:
>
> https://newrelic.com/docs/ruby/developer-mode
>
> Obviously profiling done in development mode should be taken with a
> pinch of salt, but it's usually good enough to make a start, at least.
> You can also sign up for a free trial of the full-fat account to get
> the production traces, but IIRC you'll need to hand over credit card
> details first, and they're quite eager salesmen (although always
> totally professional IME).
>
> From the description above it's hard to say what the bottleneck might
> be - hopefully the full trace in development mode will provide a few
> more clues.
Yep, the hosted version is way better at profiling and digging into
transactions than the local version. Still not ideal for profiling
view-related slowdowns, though. I've used the ruby-prof gem a fair
amount, which can be useful, but is also somewhat overwhelming,
especially when it comes to Rails view code. QueryReviewer
(http://github.com/nesquena/query_reviewer) is great for a more high
level look at where your sql time is going to, but if you're sure your
load times aren't due to sql, maybe that's not so useful.
Are you rendering a lot of partials? There's quite a bit of overhead
in setting up each partial, it can sometimes be worth flattening them
out. I ended up writing a hack that benchmarks each individual
partial and overlays the results onto the page, which has been
semi-handy...
More information about the Chat
mailing list