

How to Improve Rails Application Performance on Heroku - vanstee
http://blog.bignerdranch.com/2188-how-to-improve-rails-application-performance-on-heroku/

======
sergiotapia
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?

~~~
adamnemecek
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.

~~~
douglasisshiny
I had heard of Elastic Beanstalk but not OpsWorks. Thank you for mentioning
that.

I haven't tried it, but Cloud66 is another provider in this middle ground
(they don't host, but provide you the devops tools to do so on amazon, digital
ocean, etc.).

~~~
adamnemecek
I've heard of Cloud66. Is it any good?

~~~
douglasisshiny
I haven't tried it. It does look like a great service. One thing, however,
that I don't think it provides is auto-scaling (i.e. provisioning additional
servers or removing servers when they are (not) needed). If they were able to
provide that, I think it would rule out a need for Heroku completely.

------
gdeglin
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>

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.

------
wheaties
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
As someone pointed out in the comments section, Puma (<http://puma.io/>) is
another alternative.

------
softbuilder
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
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.

------
jbaudanza
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?

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

