Why not get yourself ONE beefy server? (or two) That should be able to handle your 150 requests per second, simplify your architecture a lot, and buying it would be cheaper than 1 month on Heroku (at $20,000/month).
Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
51–60 of 437 posts
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#52"For a Rails app, each dyno is capable of serving one request at a time."
Is this a deliberate design choice on Heroku's part, or is this just how Ruby and Rails work? It sounds bizarre that you would need multiple virtual OS instances just to serve multiple requests at the same time. What are the advantages of this over standard server fork()/threaded accept designs?
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#53Ugh. These guys are so cocky.
They are. It's in their DNA to criticize (seamlesswebsucks.com)... But they're also correct. So many reasons to hate them ;)
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#54How does this compare to EngineYard/AppFog/any other Heroku competitors?
It would be hard to say without a lot of assigned resources (money) and proper testing.
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#55Maybe this is a dumb question, but wouldn't straightforward Round Robin routing by Heroku restore their "one dyno = one more concurrent request" promise without incurring the scaling liabilities of tracking load across an arbitrarily large number of dynos?
Nope, requests could still get queued behind a dyno that's busy with a long request.
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#56Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#57I assumed people were running multiple rails processes on their dynos.
http://michaelvanrooijen.com/articles/2011/06/01-more-concur...
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#58For those of you looking to migrate to other, barer hosting solutions like AWS or another VPS provider, I've put together a Capistrano add-on that let's you use Heroku-style buildpacks to deploy with Nginx doing front-end proxy. I use it for half a dozen apps on my VPSs and it works swimmingly well. https://github.com/peterkeen/capistrano-buildpack
Doesn't that require root or at least sudo permissions for your deploy user?
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#59The cost of New Relic on Heroku looks really high because each dyno is billed like a full server, which makes it many times more expensive than if you were to manage your own large EC2 servers and just have multiple rails workers.
New Relic could be much more appealing if they had a pricing model that was based on usage instead of number of machines.
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#60i don't think some details of the argument hold. it alleges that you need more dynos to get the same throughput. but that's not true once you have sufficient demand to keep a queue of about sqrt(n) (i think - someone who knows more theory than me can correct me) in size on the dyno (where you have n dynos). because at that point all dynos will be running continuously, and the throughput will be the same with either r…
I don't think the wording's great. It's not throughput that's important, it's throughput at an acceptable latency.
You don't need 50x as many dynos to get the same throughput, you need 50x as many dynos to get the same latency characteristics at that throughput.