Rap Genius is employing a classic rap-mogul strategy: start a beef
Not only that, East Coast vs. West Coast at that...
LOL
Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
151–160 of 437 posts
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#152Why not hire a devops guy & rack your own hardware? Or get some massive computing units at amazon (just as good but more expensive)? This reminds me of the excellent 5 stages of hosting story shared on here from a while back: http://blog.pinboard.in/2012/01/the_five_stages_of_hosting/
Because the whole point is that you shouldn't have to.
[deleted]
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#153This should be more prominent. I want to love Heroku, and am sure that I could. But really, throwing in the towel at intelligent routing and replacing it with "random routing" is horrific, if true. It's arguable that the routing mesh and scaling dynamics of Heroku are a large part, if not -the- defining reason for someone to choose Heroku over AWS directly. Is it a "hard" problem? I'm absolutely sure it is. That's on…
> 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?
The requests will not be served at the same time, that's the whole point. If a request is routed to a busy dyno, you will have to wait that the previous job finish before being able to start yours.
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#154Why not hire a devops guy & rack your own hardware? Or get some massive computing units at amazon (just as good but more expensive)? This reminds me of the excellent 5 stages of hosting story shared on here from a while back: http://blog.pinboard.in/2012/01/the_five_stages_of_hosting/
Because the whole point is that you shouldn't have to.
You know, "should" is a funny thing. It's not always the same as "is".
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#155I'm inclined to wait until Heroku weighs in to render judgement. Specifically, because their argument depends on this premise: > But elsewhere in their current docs, they make the same old statement loud and clear: > The heroku.com stack only supports single threaded requests. Even if your applicaExplaintion were to fork and support handling multiple requests at once, the routing mesh will never serve more than a sin…
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/
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#156Why not hire a devops guy & rack your own hardware? Or get some massive computing units at amazon (just as good but more expensive)? This reminds me of the excellent 5 stages of hosting story shared on here from a while back: http://blog.pinboard.in/2012/01/the_five_stages_of_hosting/
Because the whole point is that you shouldn't have to.
But... you do. If you get big and need to scale, you're going to want to take the control back. Them's the breaks.
They should go dedicated for now, it's too early to colo IMO.
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#157I think this analysis and simulation does not account for one important thing: random routing is stateless and thus easy to be distributed. Routing to the least loaded Dyno needs to be stateful. It is quite easy to implement when you have one centralized router, but for 75 dynos this router would likely become a bottleneck. With many routers, intelligent routing has its own performance cost, the routers need to someh…
> With many routers, intelligent routing has its own performance cost, the routers need to somehow synchronize state, and the simulation ignores this cost.
Which is why we pay companies like Heroku to engineer clouds in which to run our applications. Because they're supposed to be better at this than us and spend the time and money building this difficult infrastructure well. That includes a scalable, stateful intelligent routing service.
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#158Take a look at deliver if you like heroku push, but want it on a machine you control at a bit lower level: https://github.com/gerhard/deliver
I got it working on EC2 / Ubuntu real easy, and even added some basic support for SmartOS/illumos for joyent cloud
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#159Aside from the Heroku issue, this is an amazing use of RapGenius for something besides rap lyrics. I didn't have to google anything in the article because of the annotations.
rap genius is definitely something bigger than rap lyrics. it could potentially be used for a platform for collectively deciphering any text.
http://rapgenius.com/Marc-andreessen-why-andreessen-horowitz...
Re: Heroku's Ugly Secret: The story of how the cloud-king turned its back on Rails
#160Good 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?
Well, at X level of concurrency, wouldn't most set ups with load balancers start to spit numbers like that?