[LRUG] Ruby on Rails - performance tuning advice

[Hemant Kumar]

Using newrelic also is a good idea for performance tuning a Rails
application. I usually use them as high level bottleneck finder in various
code paths. Works pretty well.

Once past that, I use a low level profiler if need be for further tuning of
my application.





On Wed, Mar 26, 2014 at 11:43 AM, Rory Sinclair <rory at asmallworld.net>wrote:

> 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
>
>


-- 
Cheers
Hemant
Co founder - http://www.codemancers.com
http://twitter.com/gnufied
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140326/27e8f162/attachment-0003.html>