Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Heroku Blog: Routing Performance Update

blog.heroku.com

Post reply on HN
Print view View original

101–110 of 197 posts

Re: Heroku Blog: Routing Performance Update

#101

Post by lucian1900 »

antirez wrote: post #90

Come on startups, you should be technically skilled and able to optimize in order to spend little money . If you sum EC2 and Heroku you are going to pay like 10x what it takes to run the same machines power in a dedicated server, all this because you can't handle the operations? This is absurd IMHO. Also people that want to start a business, there is a huge opportunity here , create software that makes managing Apach…

It's more like 10x from Heroku to AWS, then another order of magnitude to metal. AWS has other advantages in addition to convenience, though.

Re: Heroku Blog: Routing Performance Update

#102

Post by Rooki »

antirez wrote: post #90

Come on startups, you should be technically skilled and able to optimize in order to spend little money . If you sum EC2 and Heroku you are going to pay like 10x what it takes to run the same machines power in a dedicated server, all this because you can't handle the operations? This is absurd IMHO. Also people that want to start a business, there is a huge opportunity here , create software that makes managing Apach…

Is Canonicals Juju along the lines of what you mean? https://juju.ubuntu.com/

Re: Heroku Blog: Routing Performance Update

#103

Post by nthj »

antirez wrote: post #90

Come on startups, you should be technically skilled and able to optimize in order to spend little money . If you sum EC2 and Heroku you are going to pay like 10x what it takes to run the same machines power in a dedicated server, all this because you can't handle the operations? This is absurd IMHO. Also people that want to start a business, there is a huge opportunity here , create software that makes managing Apach…

> Also people that want to start a business, there is a huge opportunity here, create software that makes managing Apache, Redis, PostgreSQL, ..., in dedicated servers very easy and robust. Traget a popular and robust non-commercial distribution like Ubuntu LTE, and provide all is needed to deploy web nodes, database nodes, with backups, monitoring, and everything else trivial.

So the pitch is: clone Heroku, which has taken dozens of very smart engineer man-years to build and refine, then charge 5% of what the market will bear?

> "I can only write my Ruby code but can't handle operations" is not the right attitude, grow up.

I handled ops for 120+ Rails apps while managing a team of juniors and making time to write code. What a stupid waste of my time: ops is forever & never-ending, while implementing & delivering a new feature to 100K customers can bump sales' conversions permanently.

If I can outsource relatively-linearly-increasing Ops costs and instead focus on delivering value that multiplies compounding-interest style, that's not childish.

It's great business.

Re: Heroku Blog: Routing Performance Update

#105

Post by rst »

jlouis wrote: post #87

So to recap: Ruby on Rails is using a default configuration where each process can serve one request at a time. There is no cooperative switch (as in Node.js) or (near) preemptive switch (as in Erlang, Haskell, Go, ...). The routing infrastructure at Heroku is distributed . There are several routers and one router will queue at most one message per back-end dyno in the Bamboo stack and route randomly in the Cedar sta…

True for Rails 3, though you can enable threading (multiple requests per process). Rails 4 will likely default new apps threaded, but that option would still have to be manually enabled for older ones. (I say likely because there are no formal releases yet, and it's still possible stuff will get pulled back.)

Re: Heroku Blog: Routing Performance Update

#106

Post by cygwin98 »

programminggeek wrote: post #104

I feel like Heroku is punting on this one in a big way. I think this really means that for a small app, Heroku is fine, once it gets bigger, you probably want to get a real scaling strategy.

Agree. Though that's a bit ironic --- one of Heroku's selling points was scalability, at least a big part of Rails community believed it to be.

Re: Heroku Blog: Routing Performance Update

#107

Post by ig1 »

raverbashing wrote: post #96
ig1 wrote: post #94

Earlier quoted context omitted.

The primary bottleneck for most startups isn't money, it's time. Also for most startups (assuming you're not doing something CPU/bandwidth heavy) the actual cost of hosting is going to be a relatively small part of the budget. If your burn rate is a million dollars, reducing 10k of hosting costs to 1k isn't really worth the effort.

Kind of depends There's the "two guys in a dorm eating ramen" and there's the YC backed "startup" that already has a couple of hires So if your monthly budget is of hundreds of dollars, using a VPS instead of Heroku makes sense

Let say your average http request takes 200ms to serve, then with 5 heroku worker dynos you can serve about 10 million requests a day which should comfortably cover the requirements of most startups.

How much do those dynos cost ? - $143/month. That's less than three hours salary for a developer.

If your monthly budget is hundreds of dollars I'm guessing your traffic is low enough you can just use the free tiers of heroku, appfog, etc.

Re: Heroku Blog: Routing Performance Update

#108

Post by zwily »

fdr wrote: post #73
ctide wrote: post #68

Earlier quoted context omitted.

Whatever you do, get your database off Heroku. Heroku's postgres offering has sweet options, but performance is fucking awful. We went from a 20k+ month heroku bill to a fraction of that price on EC2 so we could get a slave that could keep up with the writes to our master. Performance being shit would be fine if it wasn't a miserable experience trying to migrate off. Not being able to setup replication to slaves off…

That's quite interesting; I don't see how one can really so soundly beat the disk configuration, but it certainly can be matched by something similar. It was posted about quite some time ago: http://orion.herokuapp.com/past/2009/7/29/io_performance_on_... . If this has become bad advice, inquiring minds wish to know. EBS Priops seem promising and different. Replication out of Heroku would be neat, but the WAL as-is i…

"EBS Priops seem promising and different."

We run many busy PG databases on PIOPS. The difference from normal EBS is huge. Very happy with PIOPS.

Re: Heroku Blog: Routing Performance Update

#109

Post by WillieBKevin »

tomlemon wrote: post #50

Rap Genius cofounder here. Below is the full unedited text of https://help.heroku.com/tickets/37665 , a Heroku support ticket I logged about 1 year ago. Sorry it is so long, but I think you'll find it interesting: Tom@Rapgenius| about 1 year ago I know this is a bit of a vague problem, but I've been getting a bunch of Error H12 (Request Timeout)s recently, and I'm not sure what to do about it. It's not like I have so…

I had a string of similar requests with Heroku between Feb 2011 and June 2012, before we migrated off their platform.

I would complain about h12 errors, they would tell me to upgrade my resources and/or that it was my problem and there was nothing they can do. We ended up with a solution that was easily 10x as expensive (over-powered DB, too many dynos) as our initial configuration, and it still didn't fix the issue.

I'm happy to provide the full text support requests, but they don't tend to be quite as juicy as the one you posted.

Re: Heroku Blog: Routing Performance Update

#110

Post by WillieBKevin »

jlouis wrote: post #87

So to recap: Ruby on Rails is using a default configuration where each process can serve one request at a time. There is no cooperative switch (as in Node.js) or (near) preemptive switch (as in Erlang, Haskell, Go, ...). The routing infrastructure at Heroku is distributed . There are several routers and one router will queue at most one message per back-end dyno in the Bamboo stack and route randomly in the Cedar sta…

"Forgetting who is right and wrong"

The right vs wrong issue here is not the proper way to architect a router. The issue is that Heroku glossed over an extremely important aspect of their engineering documentation, because it painted their platform in a bad light. This is particularly damning, because as an engineer working on their platform, I could design around their shortcomings as long as they don't hide them from me.

Furthermore, I believe we could make an argument Heroku intentionally misled (both in documentation and in their support responses) clients as to how their router worked.

Post reply on HN