While it’s true that the switch to random routing didn’t “degrade” performance on Cedar, that’s only because Cedar always used random routing and therefore always had terrible performance for Rails applications on thin (and other non-concurrent web servers)
Note that thin is the default web server on Cedar, so by default your Rails Cedar app will perform poorly. And of course you won’t even know it because the degradation in performance is caused by queuing that’s not measured by Heroku’s logs or New Relic
“Yesterday” (2/13/2013) is inaccurate – I started discussing the issue with Adam Wiggins (Heroku’s CTO) on 2/5/2013, and sent him the simulation results on 2/8/2013.
On 2/11/2013 he responded with an email that said:
I’m convinced that the best path forward is for one of your developers to work closely with [redacted] to modernize and optimize your web stack. If you invest this time I think it’s very likely you’ll end up with an app that performs the way you want it to at a price within your budget.
You’re correct, the routing mesh does not behave in quite the way described by the docs. We’re working on evolving away from the global backlog concept in order to provide better support for different concurrency models, and the docs are no longer accurate. The current behavior is not ideal, but we’re on our way to a new model which we’ll document fully once it’s done.
In the meantime, you shouldn’t have any difficulties as long as you keep your web requests short (less than about 500ms), which is good practice anyway.
Sorry for any difficulty or confusion, and thanks for digging in and providing such a detailed analysis.
This video is processing – it'll appear automatically when it's done.
But we need more geniuses to make this happen – right now there are only 5 members of the RG fam who program!
SO: if you are
A genius Rails programmer
A genius iOS / Android programmer
A genius front end developer who can also design
You’re down to help build the Internet Talmud (aka the best hip hop site, the best lyrics site, the best music social network, the best wikipedia for explanations of all of text, etc, etc)
HIT UP firstname.lastname@example.org with:
Your name and online identity – i.e., your Twitter, Github, Blog, Stackoverflow account, personal website, etc. The more info the better.
Location – you can’t get the true RG cult effect working remotely, so only apply if you live in NYC or are willing to relocate (our office is in Williamsburg)
Educational background and most recent job (or just send your resume or whatever)
If you come in for an interview, you’ll start by making a short technical presentation to the team and taking their questions. Generally this takes the form of “throw up a screenful of code and explain what it does / why it’s cool”, tho I’m down for whatever as long as it’s technical. What will you present?
THE MOST IMPORTANT: What have you built online that you’re proud of? Any cool designs to show off? Maybe send me some code?
This job has some pretty serious bennies!:
SICK salary & equity. You won’t be taking a pay cut to work here (unless you work for a hedge fund..)