- Use a performance monitoring solution. I use NewRelic, but only because it’s the easiest to use on Heroku and I haven’t used it’s main competitor in the Ruby app space, Skylight. Pay attention to NewRelic’s Appdex scores in particular, because they take into account the inherent variance of site response time over time. In addition, pay particular attention to time spent in the request queue for the reasons mentioned above - it’s your most important scaling metric.
- Spend time debugging your top 5 slowest web transactions on a weekly basis. Another enemy of a well-scaled web-app is performance variance. Server response times that are unpredictable or unevenly distributed require more servers to scale, even when average response times are unaffected. On a weekly basis, check in on your 5 slowest controller actions. NewRelic provides this metric for you. Treat each of those 5 slow transactions as a bug and try to close it out before the end of the week.
- Decide on a maximum acceptable server response time and treat anything more than that as a bug. One of the reasons Rails developers don’t cache enough is because they don’t know how “slow” a slow average response time is. Decide on one for your application. Most Ruby applications should be averaging less than 250ms. Less than 100ms is a great goal for a performance-focused site or a site that requires extra fast response times or has a high number of requests, like a social media site. Any action that averages more than your maximum acceptable time should be treated as a bug.
- Pay attention to swap usage. A little bit (less than 25mb) is fine. But a lot is a problem. Debug it ASAP!
- Make sure you’re excluding assets directories in your performance monitoring tools.
- Don’t forget about frontend performance.
$(document).readyis not a kitchen sink. Attaching event handlers takes time. Investigate Turbolinks and PJAX. - Eliminate N+1’s. But don’t forget to watch how much time it takes to build a complicated query.
includesand friends are not free. Always be benchmarking. - Develop with production-like data. Development databases should not be simplistic, with just a few rows. Dev databases should either be populated by a big seed file or should be copies of production data (if security/privacy concerns permit). A query that returns 10k rows in production should return 10k rows in development.
- Cache all the things. Cache it. Read my guide on caching if you haven’t already.
- Deliver assets over a CDN. How to speed up your Rails app with Cloudfront and the asset pipeline
- Use a slow-client protected webserver with multi-process I/O. You need to be protected from slow requests and you need multiple worker processes per dyno. Currently, if you’re on MRI Ruby and on Heroku, your options are Puma and Phusion Passenger 5.
Extract from: https://www.speedshop.co/2015/07/22/secrets-to-speedy-ruby-apps-on-heroku.html
Other usefull links: