4 ms·

[serious] I'm building http://techendo.co/ http://techendo.co/ and it's running rails on heroku. I was wondering if there was some easy ways to get some better

by lowglow 13y ago

[serious] I'm building http://techendo.co/ http://techendo.co/ and it's running rails on heroku. I was wondering if there was some easy ways to get some better performance out of it immediately now that we're picking up traffic. If anyone could give me some pointers or link me to a page I'd appreciate it.

RyanZAG 13y ago
Going off the techempower benchmarks, looks like you should be able to get some speedup by switching to TorqueBox. No guarantees, but if you've got the time and need the performance it could be worth testing. Here seems to be a decent guide you could follow: https://gist.github.com/bbrowning/4296297 https://gist.github.com/bbrowning/4296297
- lowglow 13y ago
  does it matter that I'm not using JRuby?
  - RyanZAG 13y ago
    You'd have to convert your gems over - you need jruby gems rather than standard ones, but apparently most gems are ported. You can read up here for more: https://devcenter.heroku.com/articles/moving-an-existing-rails-app-to-run-on-jruby https://devcenter.heroku.com/articles/moving-an-existing-rai... http://stackoverflow.com/questions/151595/jruby-on-rails-vs-ruby-on-rails-whats-difference http://stackoverflow.com/questions/151595/jruby-on-rails-vs-... So it's not just a 5 second thing, but if you have a bit of time and need performance it's something you can try.
    - lowglow 13y ago
      hm. I guess I'm not ready to switch to jruby.
awj 13y ago
That's an incredibly broad question, so it's pretty hard to answer. Here's some general ones: * More instances will give you more requests/second, but only so long as secondary system (database, search server, whatever) can keep up with the load * N+1 queries will kill your performance. They can add a lot of time to processing requests. * Everything in the most used parts of your site should hit an index on the database. If it's not I can almost guarantee it will be slow. * Look for work that you can move "offline". As long as they go out within a minute nobody will notice that you aren't sending emails at the exact time they are being generated. Move that work to a background queue so your web server can just add a queue entry and get on to the next request. * Cache anything you reasonably can. It's a lot cheaper (i.e. faster) to read from a cache than to do a database lookup. It's cheaper to read from a cache than to render an ERB template. Caching can introduce its own difficulties, but the performance gains can be worth it. Without knowing some specifics of your implementation I really can't give you better advice. Depending on the specific libraries you use it might not even be possible to move to JRuby due to support for C extensions. You might get some performance benefits out of it, but I'd expect it to only buy you some time to execute on some of the above improvements.
- lowglow 13y ago
  Thanks. :)
- pooriaazimi 13y ago
  Tools like https://github.com/MiniProfiler/rack-mini-profiler https://github.com/MiniProfiler/rack-mini-profiler really help with the N+1, and general insight into how long database calls usually take. Relevant RailsCast: http://railscasts.com/episodes/368-miniprofiler?view=asciicast http://railscasts.com/episodes/368-miniprofiler?view=asciica...
tibbon 13y ago
Make sure you're running New Relic or another monitoring service that can give you some insight into various parts of your application. If you can't see what is slow, then you can't fix it. Fixing bad queries (n+1 is a common thing that will get you in trouble), and caching API calls (Rail.cache.fetch is your friend) will help a ton. Background any tasks that must be slow. I like using Resque/Redis myself. At some point it helps to cache HTTP requests when possible too. I've been working trying to get a special Buildpack working with Nginx for better caching on Heroku, but I'm not done yet. Also make sure that you aren't serving static assets from Heroku, and you're using something like CloudFront for it. Email me if you need more help. I can normally make these things fly.

by lowglow 13y ago

RyanZAG 13y ago

Going off the techempower benchmarks, looks like you should be able to get some speedup by switching to TorqueBox. No guarantees, but if you've got the time and need the performance it could be worth testing. Here seems to be a decent guide you could follow: https://gist.github.com/bbrowning/4296297 https://gist.github.com/bbrowning/4296297

lowglow 13y ago
does it matter that I'm not using JRuby?
- RyanZAG 13y ago
  You'd have to convert your gems over - you need jruby gems rather than standard ones, but apparently most gems are ported. You can read up here for more: https://devcenter.heroku.com/articles/moving-an-existing-rails-app-to-run-on-jruby https://devcenter.heroku.com/articles/moving-an-existing-rai... http://stackoverflow.com/questions/151595/jruby-on-rails-vs-ruby-on-rails-whats-difference http://stackoverflow.com/questions/151595/jruby-on-rails-vs-... So it's not just a 5 second thing, but if you have a bit of time and need performance it's something you can try.
  - lowglow 13y ago
    hm. I guess I'm not ready to switch to jruby.

awj 13y ago

That's an incredibly broad question, so it's pretty hard to answer. Here's some general ones: * More instances will give you more requests/second, but only so long as secondary system (database, search server, whatever) can keep up with the load * N+1 queries will kill your performance. They can add a lot of time to processing requests. * Everything in the most used parts of your site should hit an index on the database. If it's not I can almost guarantee it will be slow. * Look for work that you can move "offline". As long as they go out within a minute nobody will notice that you aren't sending emails at the exact time they are being generated. Move that work to a background queue so your web server can just add a queue entry and get on to the next request. * Cache anything you reasonably can. It's a lot cheaper (i.e. faster) to read from a cache than to do a database lookup. It's cheaper to read from a cache than to render an ERB template. Caching can introduce its own difficulties, but the performance gains can be worth it. Without knowing some specifics of your implementation I really can't give you better advice. Depending on the specific libraries you use it might not even be possible to move to JRuby due to support for C extensions. You might get some performance benefits out of it, but I'd expect it to only buy you some time to execute on some of the above improvements.

lowglow 13y ago
Thanks. :)
pooriaazimi 13y ago
Tools like https://github.com/MiniProfiler/rack-mini-profiler https://github.com/MiniProfiler/rack-mini-profiler really help with the N+1, and general insight into how long database calls usually take. Relevant RailsCast: http://railscasts.com/episodes/368-miniprofiler?view=asciicast http://railscasts.com/episodes/368-miniprofiler?view=asciica...

tibbon 13y ago

Make sure you're running New Relic or another monitoring service that can give you some insight into various parts of your application. If you can't see what is slow, then you can't fix it. Fixing bad queries (n+1 is a common thing that will get you in trouble), and caching API calls (Rail.cache.fetch is your friend) will help a ton. Background any tasks that must be slow. I like using Resque/Redis myself. At some point it helps to cache HTTP requests when possible too. I've been working trying to get a special Buildpack working with Nginx for better caching on Heroku, but I'm not done yet. Also make sure that you aren't serving static assets from Heroku, and you're using something like CloudFront for it. Email me if you need more help. I can normally make these things fly.