5 ms·

How to Improve Rails Application Performance on Heroku

46 points by vanstee 14y ago

softbuilder 14y ago
tl;dr: Use New Relic and use Unicorn. Weren't these two things that the RapGenius post specifically mentioned as problematic? (Cost and memory constraints, respectively, IIRC.)
- 33degrees 14y ago
  Heroku offers the Standard New Relic tier for free, so there's no reason not to use it. The pro tier has definite advantages, but isn't required to do what is being described in the article. As for unicorn, unless your application is a real memory hog it should be possible to run 2 workers, which is a big improvement over using thin. But this is now the standard advice being given by Heroku, so there's not much new here.
misframer 14y ago
Isn't it better to use percentiles for metrics like response time? Response time might not fit a normal distribution.
wheaties 14y ago
The comment has a better point, use Blitz. I think that service is invaluable. It will push your service to the max and to a point where most applications, if seeing real traffic of that level, should be making hands over fists. I use it to crash my own hobby playground regularly. A simple Flask app (Python) I wrote can handle ~120 req/sec before it biffs it hard (all linked back to db connections allowed on the free Heroku plan.)
VeejayRampay 14y ago
As someone pointed out in the comments section, Puma (http://puma.io/ http://puma.io/) is another alternative.
sergiotapia 14y ago
I used to love Heroku but it's just too darn rigid. I hate the fact that everything is done behind the velvet curtain and I'm just assured it's "going smoothly". Last week I finally bit the bullet and bought a VPS from DigitalOcean and installed the bits and kibbles needed for Rails apps. Specifically Nginx and Passenger. Was it easy? No - but now I have total control over my machine, and my app (which let's face it, will probably never need to scale for millions of users at a time) is in my complete control. Heroku doesn't even have a local filesystem, what's up with that?
- 33degrees 14y ago
  You may have complete control, but you also have a lot more responsibility; for tuning your software, and keeping it up to date. I recently got bitten by a bug with an out of date version of apache, where the whole server would become unresponsive under heavy load; trying to update it without bringing the entire server down was a fairly stressful operation.
- adamnemecek 14y ago
  There really is a missing link between heroku and aws where one would have more control than on heroku but less devops problems than on aws. And if done right, people would be throwing money at it. I guess that is that elasticbeanstalk and opsworks are trying to solve.
  - sergiotapia 14y ago
    This is what I thought Action.io would be, but after a support ticket where I asked them about this use case, they said: === "Hi Sergio - Thanks for the note and glad you like action.io. Please keep in mind however that Action.IO is not a hosting platform - we are a cloud development platform that works with hosting providers such as Heroku, AppFog, EngineYard or Google App Engine. You can read more about how you can deploy to Heroku from Action.IO here: http://help.action.io/customer/portal/articles/1011326-deploying-rails-app-to-heroku- http://help.action.io/customer/portal/articles/1011326-deplo... === So like you said, someone fills in this hole, and a lot of people would love pay for it. I don't need to add even MORE services for something as simple as file storage for uploads.
jbaudanza 14y ago
Does anyone know how copy-on-write forking plays into the 512MB limit on Heroku? If your app takes up 256MB, does that mean you can only fit 2 workers? Shouldn't there be some savings due to copy-on-write?
gdeglin 14y ago
Doesn't this overlook the issue of Heroku's random load balancing system? This article seems to suggest that the number of Dyno's required for more load scales linearly with load but, as Heroku now admits, the routing is random and therefore scales much less efficiently. I found this great simulator that someone put together to demonstrate the issue http://ukautz.github.com/pages/routing-simulator.html http://ukautz.github.com/pages/routing-simulator.html If I'm using it correctly, in his first example using 82 dynos would actually result in requests taking over 9000ms. It takes about 150 nodes to get the average wait times down to around 600ms. Parameters used: 1. Nodes 82 2. Process/Node 1 3. Requests/second: 338 (20300/60) 4. Duration request min/max 243 5. Timeout 100000 6. Time multiplier 2.00 (not exactly sure what this does) Using multiple threads per dyno does help considerably. I guess it's equivalent to multiplying your whole dyno pool as well as having intelligent routing within the dyno itself, but problems still crop up if you have slightly inconsistent request times. Also, one problem that seems to be overlooked is the possibility that multithreading within the dyno itself is less efficient than threading across many dynos since the threads may have to compete for resources. I can imagine that performance may drop across Heroku's platform as a whole as customers switch to threaded application servers and reduce their Dyno counts.

46 points by vanstee 14y ago

tl;dr: Use New Relic and use Unicorn. Weren't these two things that the RapGenius post specifically mentioned as problematic? (Cost and memory constraints, respectively, IIRC.)

33degrees 14y ago
Heroku offers the Standard New Relic tier for free, so there's no reason not to use it. The pro tier has definite advantages, but isn't required to do what is being described in the article. As for unicorn, unless your application is a real memory hog it should be possible to run 2 workers, which is a big improvement over using thin. But this is now the standard advice being given by Heroku, so there's not much new here.

misframer 14y ago

Isn't it better to use percentiles for metrics like response time? Response time might not fit a normal distribution.

wheaties 14y ago

The comment has a better point, use Blitz. I think that service is invaluable. It will push your service to the max and to a point where most applications, if seeing real traffic of that level, should be making hands over fists. I use it to crash my own hobby playground regularly. A simple Flask app (Python) I wrote can handle ~120 req/sec before it biffs it hard (all linked back to db connections allowed on the free Heroku plan.)

VeejayRampay 14y ago

As someone pointed out in the comments section, Puma (http://puma.io/ http://puma.io/) is another alternative.

sergiotapia 14y ago

I used to love Heroku but it's just too darn rigid. I hate the fact that everything is done behind the velvet curtain and I'm just assured it's "going smoothly". Last week I finally bit the bullet and bought a VPS from DigitalOcean and installed the bits and kibbles needed for Rails apps. Specifically Nginx and Passenger. Was it easy? No - but now I have total control over my machine, and my app (which let's face it, will probably never need to scale for millions of users at a time) is in my complete control. Heroku doesn't even have a local filesystem, what's up with that?

33degrees 14y ago
You may have complete control, but you also have a lot more responsibility; for tuning your software, and keeping it up to date. I recently got bitten by a bug with an out of date version of apache, where the whole server would become unresponsive under heavy load; trying to update it without bringing the entire server down was a fairly stressful operation.
adamnemecek 14y ago
There really is a missing link between heroku and aws where one would have more control than on heroku but less devops problems than on aws. And if done right, people would be throwing money at it. I guess that is that elasticbeanstalk and opsworks are trying to solve.
- sergiotapia 14y ago
  This is what I thought Action.io would be, but after a support ticket where I asked them about this use case, they said: === "Hi Sergio - Thanks for the note and glad you like action.io. Please keep in mind however that Action.IO is not a hosting platform - we are a cloud development platform that works with hosting providers such as Heroku, AppFog, EngineYard or Google App Engine. You can read more about how you can deploy to Heroku from Action.IO here: http://help.action.io/customer/portal/articles/1011326-deploying-rails-app-to-heroku- http://help.action.io/customer/portal/articles/1011326-deplo... === So like you said, someone fills in this hole, and a lot of people would love pay for it. I don't need to add even MORE services for something as simple as file storage for uploads.

jbaudanza 14y ago

Does anyone know how copy-on-write forking plays into the 512MB limit on Heroku? If your app takes up 256MB, does that mean you can only fit 2 workers? Shouldn't there be some savings due to copy-on-write?

gdeglin 14y ago

Doesn't this overlook the issue of Heroku's random load balancing system? This article seems to suggest that the number of Dyno's required for more load scales linearly with load but, as Heroku now admits, the routing is random and therefore scales much less efficiently. I found this great simulator that someone put together to demonstrate the issue http://ukautz.github.com/pages/routing-simulator.html http://ukautz.github.com/pages/routing-simulator.html If I'm using it correctly, in his first example using 82 dynos would actually result in requests taking over 9000ms. It takes about 150 nodes to get the average wait times down to around 600ms. Parameters used: 1. Nodes 82 2. Process/Node 1 3. Requests/second: 338 (20300/60) 4. Duration request min/max 243 5. Timeout 100000 6. Time multiplier 2.00 (not exactly sure what this does) Using multiple threads per dyno does help considerably. I guess it's equivalent to multiplying your whole dyno pool as well as having intelligent routing within the dyno itself, but problems still crop up if you have slightly inconsistent request times. Also, one problem that seems to be overlooked is the possibility that multithreading within the dyno itself is less efficient than threading across many dynos since the threads may have to compete for resources. I can imagine that performance may drop across Heroku's platform as a whole as customers switch to threaded application servers and reduce their Dyno counts.