[LRUG] Ruby on Rails - performance tuning advice

[Nick Tabernacle]

The SQL-Logging gem (gem 'sql-logging') is a good help, it will give you a top 10 of SQL executions listed by total execution time in your dev env, so you can see where it’s running slowly and may need an index etc. Also has a few other helpful stats as well. 

I’d also 2nd Rory’s suggestion of Bullet.  


Nick Tabernacle  | nick at beo.so | 07515653219

On 26 Mar 2014, at 17:24, Hemant Kumar <hemant at codemancers.com> wrote:

> 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
> 
> _______________________________________________
> 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/e773dd30/attachment-0003.html>