0

So I got a rails app deployed on heroku. Nothing fancy going on, just a small custom cms, just used for uploading and editing static pages. Most of the time is just spent displaying pages, stored in the db.

There is a bit of a heavy load for each page display since the pages are stored as markdown which is then being rendered (and string-interpolatet). But even with the markdown rendering turned of, the server is still responding fairly slow (avg. 600 ms).

I'm trying to reduce the response time. The graph in New Relic tells me, that the app spends about 80 % or 90 % of its processing time, executing ruby code. I thought that I could make this faster by adding dynos, but no matter how many dynos I add, the ruby processing won't speed up. I'm currently running on just 1 dyno, so ramping it up to 4 should make it (roughly) 4 times faster, no? I tried 8 dynos but still no significant difference (not that I could afford 8 dynos anyways).

Conkerchen
  • 720
  • 1
  • 4
  • 15
  • Do you precompile assets? – Ivan Shamatov Aug 18 '14 at 09:24
  • 1
    Do you have more information about the exact ruby code that is slowing down the page? How is it distributed? Rendering, other processing, etc? The first suggestion would be to cache. There is no need to re-render the same page with the same content. – Damien Roche Aug 18 '14 at 09:24
  • You're going to dig a bit more deeply into where the time is being spent (eg using ruby-prof, stackprof etc.). For example if you're using a pureruby markdown parser/renderer then maybe you should look at a pure ruby ones. Also more dynos mean more concurrency - individual request times are unchanged – Frederick Cheung Aug 18 '14 at 09:25
  • Well like I said, even if I turn the markdown rendering off, it is almost just as slow. New Relic tells me, that the time spent is almost equally split between controller, show view, top menu partial, bottom menu partial, assets and "other". Assets are being precompiled. I might digg a bit deeper into where it spends most of its time but from this data it looks like the app simple runs pretty slow on every level. Isn't there a scalable way on heroku to get faster cpu for quicker single responses? – Conkerchen Aug 18 '14 at 15:17
  • @DamienRoche thx for the tip with caching. With Rails' `cache()` method I could reduce the avg. response-time by 1/2 for cached pages. So now, with cached pages it takes about 300 ms, 90% of wich is spent in the controller. I shall digg more into the controller now. – Conkerchen Aug 20 '14 at 06:57
  • @Conkerchen no problem. 300ms is great, but you can also do full-page caching and serve the cached content via your web server (Nginx for example, or Varnish for a focused solution). That way you don't even touch the Rails stack. Of course, full-page caching is highly dependent on your content. See here: http://over9000.org/rails/high-performance-rails-caching-with-redis-and-nginx – Damien Roche Aug 20 '14 at 08:30

0 Answers0