[LRUG] Ruby on Rails - performance tuning advice

[Karl Freeman]

I would echo both Tom and Frederick with half the challenge about
performance tuning is knowing where to look. If you haven't already I would
start adding some basic instrumentation throughout your entire stack if
you're at a loss for where time is spent. If you have a rough idea that its
somewhere in Ruby then you can get abit more specific with where to look.
For example, I tracked down a performance bottle neck once which I was
confident was a problem with Activerecord. I debugged the hell out of it to
find that it was a mutex synchronize on the instantiation of a connection
pool to an external service. Without instrumentation

Edit: User requests? I'd start instrumenting db calls, view rendering,
authorisation logic, any kind of number crunching of business logic.
Essentially the more instrumentation the better.


On 26 March 2014 14:22, Frederick Cheung <frederick.cheung at gmail.com> wrote:

>
> What instrumentation do you have in place to tell you what is slow? That's
> always the first step, so that you know whether you should be
> tuning/rewriting db queries, reimplementing an algorithm etc. We use
> newrelic in production to have an overall idea of what is going on, and
> there's ruby-prof for detailed profiling (the only danger there is because
> ruby-prof makes your ruby code run slower, it can make it seem that
> external services, db queries etc. are less of a problem than they really
> are)
>
>
> In the past I've seen performance problems fixed by
>
> - database changes: removing duplicate database queries, adding the right
> index to a query, working out that the db structure is fundamentally not
> suited to what we want to store (so either structure your data differently
> or pick a different data store. In my case we were trying to do with
> ActiveRecord what was better done with elasticsearch)
> - rewriting ruby hotspots in C (not necessarily by you - perhaps the
> problem you are trying to solve has a fast implementation you can use)
> - caching (i meant this in a very vague sense, so not just fragment
> caching etc. but in memory caching of intermediate results of calculations
> for example)
> - rewriting algorithms to suck less
>
> But all of those are step 2. Step 1 is to find your bottlenecks
> (admittedly sometimes it's more a death by a thousand cuts sort of thing)
>
> Fred
>
>
>
>
> On 26 March 2014 at 14:02:35, Nicholas Martin (nic_i_like_to_ at hotmail.com)
> wrote:
> > Hi,
> > We are currently working to improve performance of our Rails application.
> > There is a lot of information out there in the Rails Guides and various
> blog posts.
> > However, the challenge is finding what things will give us the best
> results. For example,
> > in the work we have done so far, code changes to aggregate data have
> helped a lot, caching
> > less so.
> > Any advice, based on experience would be most appreciated. Any form
> would be of interest,
> > from a short reply, to a chat over a coffee or even potentially a day or
> so of consultancy.
> > Cheers,Nic.
> > _______________________________________________
> > Chat mailing list
> > Chat at lists.lrug.org
> > http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> >
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140326/984887c1/attachment.html>