<div dir="ltr">I would echo both Tom and Frederick with half the challenge about performance tuning is knowing where to look. If you haven't already I would start adding some basic instrumentation throughout your entire stack if you're at a loss for where time is spent. If you have a rough idea that its somewhere in Ruby then you can get abit more specific with where to look. For example, I tracked down a performance bottle neck once which I was confident was a problem with Activerecord. I debugged the hell out of it to find that it was a mutex synchronize on the instantiation of a connection pool to an external service. Without instrumentation<div>
<br></div><div>Edit: User requests? I'd start instrumenting db calls, view rendering, authorisation logic, any kind of number crunching of business logic. Essentially the more instrumentation the better.</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On 26 March 2014 14:22, Frederick Cheung <span dir="ltr"><<a href="mailto:frederick.cheung@gmail.com" target="_blank">frederick.cheung@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What instrumentation do you have in place to tell you what is slow? That's always the first step, so that you know whether you should be tuning/rewriting db queries, reimplementing an algorithm etc. We use newrelic in production to have an overall idea of what is going on, and there's ruby-prof for detailed profiling (the only danger there is because ruby-prof makes your ruby code run slower, it can make it seem that external services, db queries etc. are less of a problem than they really are)<br>
<br>
<br>
In the past I've seen performance problems fixed by<br>
<br>
- database changes: removing duplicate database queries, adding the right index to a query, working out that the db structure is fundamentally not suited to what we want to store (so either structure your data differently or pick a different data store. In my case we were trying to do with ActiveRecord what was better done with elasticsearch)<br>
- rewriting ruby hotspots in C (not necessarily by you - perhaps the problem you are trying to solve has a fast implementation you can use)<br>
- caching (i meant this in a very vague sense, so not just fragment caching etc. but in memory caching of intermediate results of calculations for example)<br>
- rewriting algorithms to suck less<br>
<br>
But all of those are step 2. Step 1 is to find your bottlenecks (admittedly sometimes it's more a death by a thousand cuts sort of thing)<br>
<br>
Fred<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
On 26 March 2014 at 14:02:35, Nicholas Martin (<a href="mailto:nic_i_like_to_@hotmail.com">nic_i_like_to_@hotmail.com</a>) wrote:<br>
> Hi,<br>
> We are currently working to improve performance of our Rails application.<br>
> There is a lot of information out there in the Rails Guides and various blog posts.<br>
> However, the challenge is finding what things will give us the best results. For example,<br>
> in the work we have done so far, code changes to aggregate data have helped a lot, caching<br>
> less so.<br>
> Any advice, based on experience would be most appreciated. Any form would be of interest,<br>
> from a short reply, to a chat over a coffee or even potentially a day or so of consultancy.<br>
> Cheers,Nic.<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<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>
<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>
</div></div></blockquote></div><br></div>