<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Hi all,<div><br></div><div>Thank you all for your suggestions.  Its very much appreciated and gives me some good new leads!</div><div><br></div><div>Nic.</div><div><div><hr id="stopSpelling">Date: Wed, 26 Mar 2014 15:43:22 +0000<br>From: rory@asmallworld.net<br>To: nic_i_like_to_@hotmail.com<br>CC: chat@lists.lrug.org<br>Subject: Re: [LRUG] Ruby on Rails - performance tuning advice<br><br>
                <div style="font-family:Helvetica;font-size:13px;">Hi,<div><br></div><div>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:</div><div><br></div><div>On the client tier:</div><div><br></div><div>- 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)</div><div><br></div><div>- 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</div><div><br></div><div>- caching API responses - shared cache for public stuff / stuff thats the same for all users, and a per-user cache for ‘private’ stuff</div><div><br></div><div>- prefetching API endpoint data in parallel to warm caches</div><div><br></div></div><div><div>On the API back-end tier:</div><div><br></div><div>- using Ruby-Prof - https://github.com/ruby-prof/ruby-prof - to spit out useful HTML graphs of where time is being spent</div><div><br></div><div>- using Bullet - https://github.com/flyerhzm/bullet - to identify cases where we should be eager loading but weren’t</div><div><br></div><div>- JMeter to hit every API endpoint multiple times concurrently, and graph average response times to identify</div><div><br></div><div>- generally reducing cruft, simplifying code paths, auditing code to ensure we’re not doing unnecessary work, etc</div><div><br></div><div>Thanks Graham for the tip about Rack Mini Profiler - will check that out.</div><div><br></div><div>Regards</div><div><br></div><div>-- </div><div>Rory Sinclair<br></div><div>Head of Technology</div><div>ASMALLWORLD</div><div><br></div></div>
                 
                <p style="color:#A0A0A8;">On Wednesday, 26 March 2014 at 15:14, Graham Ashton wrote:</p>
                <blockquote style="border-left-style:solid;border-width:1px;padding-left:10px;">
                    <span><div><div><div>On 26 Mar 2014, at 14:02, Nicholas Martin <<a href="mailto:nic_i_like_to_@hotmail.com">nic_i_like_to_@hotmail.com</a>> wrote:<br><br></div><blockquote><div><div dir="ltr"><div>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.</div></div></div></blockquote><div><br></div>As others have already said, you need to measure things before you act.<div><br></div><div>The best tool I've come across for measuring performance of Rails apps is Rack MiniProfiler.</div><div><br></div><div><a href="https://github.com/miniprofiler/rack-mini-profiler" target="_blank">https://github.com/miniprofiler/rack-mini-profiler</a></div><div><br></div><div>I recommend watching the RailsCast to get yourself up to speed.</div><div><br></div><div>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.<br><div><br></div><div>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.</div><div><br><blockquote><div><div dir="ltr"><div>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.</div></div></div></blockquote><div><br></div>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...</div><div><br></div><div>Cheers,</div><div>Graham</div></div></div><div><div>_______________________________________________</div><div>Chat mailing list</div><div><a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a></div><div><a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a></div></div></div></span>
                 
                 
                 
                 
                </blockquote>
                 
                <div>
                    <br>
                </div></div></div>                                      </div></body>
</html>