[LRUG] Ruby on Rails - performance tuning advice

[Nicholas Martin]

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 TechnologyASMALLWORLD

                 
                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 listChat at lists.lrug.orghttp://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/a8be1349/attachment-0003.html>