[LRUG] Ruby on Rails - performance tuning advice

Luca Mearelli l.mearelli at spazidigitali.com
Thu Mar 27 01:22:09 PDT 2014


I second what the others have said, and if I may add just reinforce a
couple of suggestions:

- Measure! You can't improve or won't be able to assess IF you have
improved if you don't have any objective metrics to guide the process.
Newrelic (even their free tier) is great for that, but also very simple
grepping / awking of the logs could help establish a baseline

- optimizing on the client side helps a lot with the speed as *perceived*
by the users (as Rory wrote: use a CDN, assets optimization). I find Google
PageSpeed (http://developers.google.com/speed/pagespeed/insights/) is a
good companion to yslow.

- use caching wisely and use a memory based store for that. It is rearely
possibile to use widely across most of the pages, but often I found once I
fixed obvious data access issues, rendering time was the worst offender
(and caching helps with that).

btw I didn't know bullet, thanks for the tip!

--
Luca Mearelli
http://getproductionready.com
http://spazidigitali.com



On Wed, Mar 26, 2014 at 11:23 PM, Nicholas Martin <
nic_i_like_to_ at hotmail.com> wrote:

> Hi all,
>
> Thank you all for your suggestions.  Its very much appreciated and gives
> me some good new leads!
>
> Nic.
> ------------------------------
> Date: Wed, 26 Mar 2014 15:43:22 +0000
> From: rory at asmallworld.net
> To: nic_i_like_to_ at hotmail.com
> CC: chat at lists.lrug.org
>
> Subject: Re: [LRUG] Ruby on Rails - performance tuning advice
>
> Hi,
>
> We've been doing some performance enhancement of our platform lately,
> which is a two-tier architecture (JSON API backend, Rails frontend web
> app).  Here's whats helped:
>
> On the client tier:
>
> - using the yslow plugin for Firebug to identify things we needed to tweak
> on the web side (CDN for static assets, using a separate domain for assets,
> etc)
>
> - reducing quality on large images to get the sizes down - this was a big
> deal, since all the usual 'lossless' compression tools were saving us next
> to nothing
>
> - caching API responses - shared cache for public stuff / stuff thats the
> same for all users, and a per-user cache for 'private' stuff
>
> - prefetching API endpoint data in parallel to warm caches
>
> On the API back-end tier:
>
> - using Ruby-Prof - https://github.com/ruby-prof/ruby-prof - to spit out
> useful HTML graphs of where time is being spent
>
> - using Bullet - https://github.com/flyerhzm/bullet - to identify cases
> where we should be eager loading but weren't
>
> - JMeter to hit every API endpoint multiple times concurrently, and graph
> average response times to identify
>
> - generally reducing cruft, simplifying code paths, auditing code to
> ensure we're not doing unnecessary work, etc
>
> Thanks Graham for the tip about Rack Mini Profiler - will check that out.
>
> Regards
>
> --
> Rory Sinclair
> Head of Technology
> ASMALLWORLD
>
> On Wednesday, 26 March 2014 at 15:14, Graham Ashton wrote:
>
> On 26 Mar 2014, at 14:02, Nicholas Martin <nic_i_like_to_ at hotmail.com>
> wrote:
>
> 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.
>
>
> As others have already said, you need to measure things before you act.
>
> The best tool I've come across for measuring performance of Rails apps is
> Rack MiniProfiler.
>
> https://github.com/miniprofiler/rack-mini-profiler
>
> I recommend watching the RailsCast to get yourself up to speed.
>
> It's so quick and easy to install and use that I run it permanently in
> development, which helps me avoid big performance related oversights when
> building new features.
>
> You'll obviously get different performance characteristics in production,
> with production hardware and the real users' data. Unlike most profiling
> tools, Rack MiniProfiler has been designed to run in production too.
>
> 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.
>
>
> I'd be happy to take a look at it on a consultancy basis if you like -
> ping me an email if you're interested. I wouldn't be surprised if a couple
> of hours with the profiler highlighted your low hanging fruit though...
>
> Cheers,
> Graham
> _______________________________________________
> 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/20140327/d5529f28/attachment-0003.html>


More information about the Chat mailing list