[seivan]

Wait, so those guys were on Bamboo, and complaining? Fuck, that is so not cool.

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)

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

[tomlemon]

Rap Genius cofounder:

Random routing is still wayyyyy worse than intelligent routing even if you're processing multiple requests simultaneously on a single dyno (see http://rapgenius.com/1504222)

Requests will still queue, but since time spent queuing at the dyno level doesn't appear in your logs or on New Relic, you'll never know it.

[cpressey]

I think that's one of the real tragedies under all this, and compounding the tragedy is that it's going under-discussed: the performance monitoring is incomplete. If the dyno level queue time was apparent, this issue would have become obvious much sooner.

[richcollins]

Does Cedar solve the problem? Random routing can still end up overloading a dyno. What's the solution?

[badgar]

No, you are correct, and move to AWS.

[niggler]

"Wait, so those guys were on Bamboo, and complaining? Fuck, that is so not cool."

That's a non-sequitur given that Heroku still supports it and didn't advocate migrating in their response.

It's fair to complain about a bug in Lion or in Windows 7 or in other products that are stil being supported. It's unfair to rail about a windows 95 bug, for example, but not something which is still being supported. And I'm surprised heroku didnt suggest Cedar in the response itself.

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

[achalkley]

Bamboo is no longer running now.

[benatkin]

I think you're mistaken. New Bamboo apps can't be created, but apps that were created as Bamboo or migrated from Aspen to Bamboo before Bamboo was turned off are still running.

[achalkley]

Right! The Aspen stack was shut down. My mistake! I thought they were only offering Cedar.