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

Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails

rapgenius.com

Post reply on HN
Print view View original

391–400 of 437 posts

Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails

#391

Post by mcherm »

vicks711 wrote: post #352
humbledrone wrote: post #318

Earlier quoted context omitted.

Normally I would just downvote you and move on, but in this case your comment is frustrating enough that I have to say something. I found the comment you responded to (by nsrivast) quite fascinating. A well-written but brief analysis of the problem, with sources attached for further reading -- what's not to like? In-depth and thoughtful comments like that are what keep me coming back to this site, and are what make t…

really?

Yes. Really. Some people[1] spend their time writing lengthy and technical posts about specific technical issues. The rest of the world benefits from this. And the person writing the post benefits too, because trying to write something like that makes you smarter. Perhaps you should try it sometime.

[1] - I occasionally do this.

Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails

#392

Post by Ingaz »

ajanuary wrote: post #335
DeepDuh wrote: post #234

Earlier quoted context omitted.

As others here have pointed out in different discussions: Ideas aren't worth much by themselves. It's the subset that's implementable of which it's the subset that has gotten implemented that's worth anything. If we just love ideas we should better become philosophers. Sorry to be a bit harsh, but I find it a bit shocking how even in this field where we can basically play god and do whatever we want and what we think…

They want to love it because the idea is great. They don't love it because it doesn't deliver. Sounds like you both agree.

"Love" is complicated matter.

Java is almost done from "Love".

Rails is done from "Love" of those who do not "love" java.

Hype.

I don't "love" java and Rails.

Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails

#393

Post by chc »

vidarh wrote: post #388
joseph_cooney wrote: post #244

Earlier quoted context omitted.

How many web requests are typically CPU bound though? Not many.

Doesn't matter. At some point you hit memory limits, disk IO limits, or simply a connection limit. It doesn't matter what limit: If you have some requests that are longer running than others, random load balancing will make them start piling up once you reach some traffic threshold. You can increase the threshold by adding more backends or increasing the capacity of each backend (by optimizing, or picking beefier har…

> But no matter what you do, you end up having to allocate more spare resources at it than what you would need with more intelligent routing.

I think we have to remember that the "intelligent routing" in question here is actually marketing-speak for "one request per server." Are you saying that when your servers can only receive one request at a time, you will necessarily need fewer than if your servers can handle three requests at a time but are assigned requests randomly?

Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails

#394

Post by steveklabnik »

ylansegal wrote: post #247
spoiler wrote: post #155

Earlier quoted context omitted.

Slightly off topic, but what are everyone's. experience and thoughts about Puma[1]? I am using it on a small production environment with Heroku and I like it, but when we officially launch the app, should we switch to Unicorn? [1] http://puma.io/

I did some performance analysis on puma vs unicorn vs thin a while ago: http://ylan.segal-family.com/blog/2012/08/20/better-performa... Although as noted in the comments, I neglected to run threadsafe! and should have probably tried rubinius or jruby. I have been meaning to redo. Take with a grain of salt

Also note that Rails 4 will have threadsafe! on by default, too, so if you didn't have it on here, that'll make it different for those apps.

Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails

#395

Post by baudehlo »

encoderer wrote: post #251
Scramblejams wrote: post #233

Earlier quoted context omitted.

I don't know, $20k/mo strikes me as an awful lot of money to avoid engaging in work that a scrappy internet startup really ought to be competent at. If you don't know how to run the pipes and they get clogged and your plumber's not picking up the phone, you're screwed. That amount buys a whole lotta dedicated servers and the talent to run them. (Sidenote: Every time I price AWS or one of its competitors for a reasona…

Three thoughts: 1. Employees are expensive. A good ops guy who believes in your cause and wants to work at an early stage startup can be had for $100k. (Maybe NYC is much cheaper than the bay area, but I'll use bay area numbers for now because it's what I know). That's base. Now add benefits, payroll taxes, 401k match, and the cost of his options. So what... $133k?. That's one guy who can then never go on vacation or…

Your last sentence hides another option which is the route we took: outsource devops. It cost us about $2000 in consultant fees for a fully setup system, easy to expand and add hardware to, and much more cost effective long term than AWS or Heroku. Our guy runs a small ops company who have 24/7 on-call. It's really the perfect solution.

Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails

#396

Post by izietto »

From the Heroku docs:

[...] Request distribution

The routing mesh uses a random selection algorithm for HTTP request load balancing across web processes. [...]

If the algorithm is random, the load balancing simply doesn't happen, am I wrong?

https://devcenter.heroku.com/articles/http-routing#request-d...

Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails

#397

Post by frankc »

I know nothing about Heroku's architecture than what I just read in this post, but couldn't you alleviate this problem greatly by having the dyno's implement work stealing? Obviously the they would have to know about each other then, but perhaps that is easier to do that global intelligent routing.

Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails

#398

Post by mieubrisse »

jcromartie wrote: post #361
nsrivast wrote: post #262

OP is a friend of mine, and when I first heard of his problem I wondered if there might be an analytical solution to quantify the difference between intelligent vs naive routing. I took this problem as an opportunity to teach myself a bit of Queueing Theory[1], which is a fascinating topic! I'm still very much a beginner, so bear with me and I'd love to get any feedback or suggestions for further study. For this exam…

Just a little thing: why can't we just say "servers" and "requests" instead of "registers" and "customers", because stores don't get 9000 customers per minute and don't have 500 registers. Everybody here would understand servers and requests.

Though I'm aware of the basics of request routing, forming a real-world analogy that's more tangible definitely helped me grok the explanation.

Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails

#399

Post by chc »

Dylan16807 wrote: post #242
chc wrote: post #115

Earlier quoted context omitted.

> But really, throwing in the towel at intelligent routing and replacing it with "random routing" is horrific, if true. The thing is, their old "intelligent routing" was really just "we will only route one request at a time to a dyno." In other words, what changed is that they now allow dynos to serve multiple requests at a time. When you put it that way, it doesn't sound as horrific, does it?

Yes it does sound as horrific. It should never route more than N requests to a dyno, where N is the number of requests it can handle simultaneously. It doesn't matter if N is 1, 2, or 10. And it should always send new requests to the emptiest dyno.

While I agree that routing to the emptiest dyno would be a good thing, I think it's a little melodramatic to describe giving every dyno at least three times and up to several thousand times as much power as "horrific."

Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails

#400

Post by JPKab »

lkrubner wrote: post #143

Good lord!!!!! Percentage of the requests served within a certain time (ms) 50% 844 66% 2977 75% 5032 80% 7575 90% 16052 95% 20069 98% 29282 99% 30029 100% 30029 (longest request) Those numbers are amazingly awful. If I ever run ab and see 4 digits I assume I need to optimize my software or server. But 5 digits? Why in the world would a company spend $20,000 a month for service this awful?

I've been scanning through the comments, and I have yet to see anything written by a Heroku engineer to defend the company. I'm hoping its in here and I missed it. I have a feeling that this all might be absolutely true, and they have lawyers/PR trying to think of a damage control plan.

I suspect that the reason they'be been pushed to do this is financial, and it makes me think that Nodejitsu's model of simply not providing ANY free plans other than one month trials is a good one. I realize it's apples and oranges, since NJ is focused on async and this wouldn't even be a problem for a Node app, but from a business perspective I feel like this would alleviate pressure. How many dynos does Heroku have running for non-paying customers? Do these free dynos actually necessitate this random routing mesh bullshit? If not, what?

Post reply on HN