[badgar]

> We've been on cedar ever since it launched, and been running puma threads or unicorn workers. The idea of one dyno per request is bullshit, and I wasn't sure if they were on cedar or not. A dyno is an allocated resource (512mb, not counting db, k/v store etc)

It doesn't matter if you think one dyno per request is "bullshit" or not, Rails isn't multithreaded, so what do you propose they do? Using unicorn_rails on Cedar lets you fork off a few subprocesses to handle more requests on the dyno queue which gets you a constant factor bite at the dyno queue lengths, a few weeks or months of scale at best - it's not a real solution.

Heroku knows that Rails on Cedar is just as affected by their inability to route requests and they're only not copping to it in this blog post because they don't have a customer running Cedar complaining so loudly. Which is cowardly.

> How ballsy of them to complain when they are doing it wrong.

If you mean that deploying a rails app to Heroku is doing it wrong - a sentiment many are agreeing with right now - then yes, you're correct!

[btilly]

If you pay attention to queueing theory, you'd know that even a modest amount of parallelism per worker will let you run much closer to capacity while still having very few bad request pileups.

Another way to put that is that using Cedar lets you get acceptable end user performance with far fewer dynos.

[jrochkind1]

> It doesn't matter if you think one dyno per request is "bullshit" or not, Rails isn't multithreaded

Sure it is. You just have to set `config.threadsafe!`, which right now is slated to be on by default in rails4.

But then you need a server stack that supports multi-threaded requests, such as puma which the parent comment mentioned using.

And then if you're using MRI, your multiple threads in a process still can't use more than one cpu at a time -- but this _probably_ doesn't matter in the scenario we're talking about, because a single heroku dyno isn't going to have access to more than one cpu at a time anyway, right?

How this all shakes out is indeed confusing. I am _not_ saying "If you just use puma and config.threadsafe!" all is well with their scheduler. I do not know one way or the other, it is hella confusing.

But it is incorrect to say "Rails isn't multithreaded, so what do you propose they do"

[steveklabnik]

> Rails isn't multithreaded, so what do you propose they do?

Rails does have config.threadsafe!, and it will be on by default in Rails 4. http://tenderlovemaking.com/2012/06/18/removing-config-threa...