<div dir="ltr"><div>I second what the others have said, and if I may add just reinforce a couple of suggestions:</div><div><br></div><div>- 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</div>
<div><br></div><div>- 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 (<a href="http://developers.google.com/speed/pagespeed/insights/">http://developers.google.com/speed/pagespeed/insights/</a>) is a good companion to yslow.</div>
<div><br></div><div>- 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).</div>
<div><br></div><div>btw I didn't know bullet, thanks for the tip!</div><div><br></div><div>--</div><div>Luca Mearelli</div><div><a href="http://getproductionready.com">http://getproductionready.com</a></div><div><a href="http://spazidigitali.com">http://spazidigitali.com</a></div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 26, 2014 at 11:23 PM, Nicholas Martin <span dir="ltr"><<a href="mailto:nic_i_like_to_@hotmail.com" target="_blank">nic_i_like_to_@hotmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><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><div class="hm HOEnZb">Date: Wed, 26 Mar 2014 15:43:22 +0000<br>
From: <a href="mailto:rory@asmallworld.net" target="_blank">rory@asmallworld.net</a><br>To: <a href="mailto:nic_i_like_to_@hotmail.com" target="_blank">nic_i_like_to_@hotmail.com</a><br>CC: <a href="mailto:chat@lists.lrug.org" target="_blank">chat@lists.lrug.org</a></div>
<div class=""><br>Subject: Re: [LRUG] Ruby on Rails - performance tuning advice<br><br>
</div><div><div class="h5"><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 - <a href="https://github.com/ruby-prof/ruby-prof" target="_blank">https://github.com/ruby-prof/ruby-prof</a> - to spit out useful HTML graphs of where time is being spent</div>
<div><br></div><div>- using Bullet - <a href="https://github.com/flyerhzm/bullet" target="_blank">https://github.com/flyerhzm/bullet</a> - 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" target="_blank">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" target="_blank">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></div> </div></div>
<br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div>