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

Rap Genius (YC S11) responds to Heroku’s call for ‘respect’

venturebeat.com

Post reply on HN
Print view View original

81–90 of 93 posts

Re: Rap Genius (YC S11) responds to Heroku’s call for ‘respect’

#81

Post by PommeDeTerre »

DeepDuh wrote: post #75
tvladeck wrote: post #55

It doesn't matter how efficient or inefficient RG was with their Rails app. It's almost certainly true that they could have done things better on their end, and their performance penalty wouldn't have been as severe -- but that really is not the point. The point is that one company promised a level of service with their product that they did not deliver, and the difference was significant and persistent. The fact tha…

Yes, the comment quality on HN seems to be quite bad when it comes to Heroku threads. Why do so many CS professionals appear to be attaching themselves emotionally to software tools? That's pretty much what I have to conclude if you can't admit that this PaaS provider has screwed up and deserves more scrutiny when deciding for the platform of your next project/migration. Isn't one of the great things about the Softwa…

I'm not really certain why, but there is a much greater tendency for members of the Ruby community to get emotionally attached to certain tools or services, and to defend them unequivocally, even when this is completely unjustified.

I haven't seen this to such a high degree with any other programming language/platform/technology community. Yes, there are developers in these communities who do prefer certain tools, but they're generally reasonable when it comes to criticism of these tools, or the suggestion of using alternatives. It's much rarer to see this when dealing with Ruby developers.

On more than one occasion, I've witnessed several different Ruby developers yell and scream in meetings when told they can't use a particular library or framework. I've never seen this kind of reaction from the many Java, C#, C, C++, Fortran, COBOL, Ada, Perl or Python developers I've worked with over the years, for instance.

Re: Rap Genius (YC S11) responds to Heroku’s call for ‘respect’

#82

Post by PommeDeTerre »

grey-area wrote: post #77
benologist wrote: post #6

Reading things like 512mb isn't enough for more than one request at a time, and one request at a time, and the performance of that one request looking terrible even though it's obviously got an entire vm dedicated to it... What are (edit:) Rails developers getting in exchange for these enormous penalties that makes it worth choosing?

Most rails apps use nothing like that amount of memory, the norm is more like 80-150MB. There are various factors which affect how much memory you use and of course if your processes are leaking memory they could easily grow over time and hit any limit. Rails itself is taking up around 30MB, so this is all about the specific app code. Another common problem is loading lots of records into memory (say fetching all you…

I find it completely astounding that 80+ MB of memory is required to run these Ruby web apps.

I remember doing CGI development in Perl back in the 1990s. We were lucky if our web servers had 32 MB of physical RAM, yet we could easily handle many requests per second to our CGI scripts with a single server. I don't think that the apps then were all that different from what we have today. They still had to interact with databases, perform string manipulation and other logic, and generate and emit HTML.

So it just seems really bad to me that Ruby on Rails requires so much more memory for doing basically the same task. Something is seriously wrong.

Re: Rap Genius (YC S11) responds to Heroku’s call for ‘respect’

#83

Post by vannevar »

sologoub wrote: post #35

This entire thing against Heroku is so disingenuous... The fact that New Relic didn't expose these metrics is not great, but has very little to do with Rap Genius team not knowing about the metric. Apparently, the fact that requests can be queued at Dyno level was common public knowledge back in 2011! Here's a quote from Stackoverflow answer: "Your best indication if you need more dynos (aka processes on Cedar) is yo…

The problem wasn't that queuing delay was impossible to detect. The problem was that the documentation described a specific load balancing setup that would have guaranteed better performance per dyno, and that setup was not in fact what was being delivered. It was clearly a material misrepresentation, and in any other service context would constitute a deceptive trade practice. That Heroku is being defended at all is a testament to the goodwill they've built up in the tech community, but it doesn't change the fact that they misrepresented their service, even if it was negligence rather than malice.

Re: Rap Genius (YC S11) responds to Heroku’s call for ‘respect’

#84

Post by grey-area »

PommeDeTerre wrote: post #82
grey-area wrote: post #77

Earlier quoted context omitted.

Most rails apps use nothing like that amount of memory, the norm is more like 80-150MB. There are various factors which affect how much memory you use and of course if your processes are leaking memory they could easily grow over time and hit any limit. Rails itself is taking up around 30MB, so this is all about the specific app code. Another common problem is loading lots of records into memory (say fetching all you…

I find it completely astounding that 80+ MB of memory is required to run these Ruby web apps. I remember doing CGI development in Perl back in the 1990s. We were lucky if our web servers had 32 MB of physical RAM, yet we could easily handle many requests per second to our CGI scripts with a single server. I don't think that the apps then were all that different from what we have today. They still had to interact with…

I find it completely astounding that 80+ MB of memory is required to run these Ruby web apps.

Because memory is cheap nowadays, people use more of it, in the same way that most desktop OSs now couldn't boot on a 32MB machine, and often require something like 2GB of RAM just to function acceptably. Like money inflation, sometimes this is hard to accept :)

Of course Rails comes with a whole load of convenience code built in, which is loaded for each process and not always shared, people use gems, which are also loaded, people add apps on top, and people use in-memory caches etc. Those figures I quoted are for real world apps which pull in quite a lot of other code, though they are just taken from top/passenger-memory-stats, so take that with a pinch of salt. People use all that code because it's easier than reinventing the world each time, and developer time costs more than memory over the long term as sites are developed.

If you want to cut things right down, hello world in rails is around 40MB. Sinatra (another rack-based Ruby framework) does less and consumes about 20MB per process, so less again. A bare-bones script doing direct db access and some string manipulation (similar to those you were running back in the 90s) would probably take far less again and fit easily on your 32MB server, or of course perl is perfectly adequate too and might take less again (sorry no idea there) if you don't use a framework.

I suspect for most frameworks that you might use in perl though you'd see similar resource usage nowadays, simply because the resources are there and there is less cost for memory, and more cost for development time. Would be interesting to see figures for other frameworks/platforms which do similar work to Rails, as many are probably better on this front. Revel in Go for example takes around 5MB for a simple app, but it does far less at present - I suspect it'd remain far better for memory and performance though, even with extras like an ORM.

Re: Rap Genius (YC S11) responds to Heroku’s call for ‘respect’

#86

Post by cbs »

sologoub wrote: post #35

This entire thing against Heroku is so disingenuous... The fact that New Relic didn't expose these metrics is not great, but has very little to do with Rap Genius team not knowing about the metric. Apparently, the fact that requests can be queued at Dyno level was common public knowledge back in 2011! Here's a quote from Stackoverflow answer: "Your best indication if you need more dynos (aka processes on Cedar) is yo…

Here's a quote from Stackoverflow answer

I tend to read (and trust) official documentation before Stack Overflow. I use Stack Overflow and it is great tool and all, but it can be really hit or miss. It doesn't cover every corner of every tech, and unless the answer is availible somewhere on the internet, or the person answering has first-hand experience it can lead to misleading wishy-washy answers.

Ultimately, pointing to SO you're lowering the expectations of a paid service from "the documentation reflects the product" so damn low to the point of "users should read everything googleable about the product they're using, and trust that OVER the official docs. Including mailing list posts from 2011 and a stack overflow question that asks a different question than you're asking"

Re: Rap Genius (YC S11) responds to Heroku’s call for ‘respect’

#87

Post by Sujan »

mbell wrote: post #54
Sujan wrote: post #16

Earlier quoted context omitted.

1. They acknowledged the problem 2. They wrote several blog posts explaining what happened and what is going to happen now (fixing) and in the future (more fixing) 3. They fixed their documentation 4. They helped a third party service to adapt their offering to better help their customers (NewRelic) 5. They offered their advice for better solutions for affected customers (Unicorn) This sounds a lot like fixing to me.…

> 4. They helped a third party service to adapt their offering to better help their customers (NewRelic) Unless I misunderstand the situation, NewRelic's heroku reporting isn't some one sided third party service but rather something that at least seems to be jointly produced by Heroku and NewRelic. NewRelic can't report something that isn't offered up and it would seem to me that Heroku needs to deliberately expose m…

I'm not entirely sure if the headers the new version of the plugin uses were available before, but it sounded like they were. NR wasn't aware that the one they were using didn't report the queueing time before the dynos and Heroku now helped them to fix that.

So yeah, probably Heroku fixed their part and made sure NewRelic reflected that.

Re: Rap Genius (YC S11) responds to Heroku’s call for ‘respect’

#88

Post by cbs »

benologist wrote: post #78
DeepDuh wrote: post #75

Earlier quoted context omitted.

Yes, the comment quality on HN seems to be quite bad when it comes to Heroku threads. Why do so many CS professionals appear to be attaching themselves emotionally to software tools? That's pretty much what I have to conclude if you can't admit that this PaaS provider has screwed up and deserves more scrutiny when deciding for the platform of your next project/migration. Isn't one of the great things about the Softwa…

Everyone knows Heroku screwed up, there not much left to say about that part of this story... so then we get to the application.

there not much left to say about that part of this story... so then we get to the application.

If we're going to be bikeshedding, why bikeshed RapGeinus' rails app, surely Heroku's request routing is a more meaty and exciting problem to talk about? Or is it simply because rails is a known quantity it is easier to fling shit at RG for not having the foresight to make exactly the decisions that are obvious to people with hindsight and an incomplete view of their application?

Re: Rap Genius (YC S11) responds to Heroku’s call for ‘respect’

#89

Post by gregd »

olefoo wrote: post #69

I'm not Heroku's biggest fan, and haven't used it for more than a couple of one-off fiddles to play with the platform. But, my sympathy is going to them, because what I see coming from Rap Genius looks like classic blame-game. So a vendors documentation was unclear and your server sucked publicly for some time? Shameful. You didn't know about it because you expected your vendors to give you extra hand-holding? That's…

I'm having a hard time understanding your justification for your sympathy going to Heroku.

RG is paying for PaaS from Heroku based on documentation, sales pitches, etc. They're also paying good money for the tools necessary to make business decisions based on data collected from that PaaS. Just given the realm of customer service, why wouldn't you expect "hand-holding" from your vendor? Why is it unreasonable to have that expectation? Why is it acceptable for your vendor to have a fall down response in "optimize your web-stack"? How do you expect them to "fix" this problem without the vendors involvement? What did you expect them to do, change platforms? How are they supposed to "move on" when the issue hasn't been resolved?

Have we gotten so far away from customer service with the likes of Google, that we don't even know what that means anymore? Are we to settle for mediocrity from any PaaS because our expectations are just too high?

Re: Rap Genius (YC S11) responds to Heroku’s call for ‘respect’

#90

Post by benologist »

cbs wrote: post #88
benologist wrote: post #78

Earlier quoted context omitted.

Everyone knows Heroku screwed up, there not much left to say about that part of this story... so then we get to the application.

there not much left to say about that part of this story... so then we get to the application. If we're going to be bikeshedding, why bikeshed RapGeinus' rails app, surely Heroku's request routing is a more meaty and exciting problem to talk about? Or is it simply because rails is a known quantity it is easier to fling shit at RG for not having the foresight to make exactly the decisions that are obvious to people wi…

Nobody's bikeshedding anything.... Heroku have admitted it's a real problem, they have begun addressing it and increasing visibility and awareness into it. There is no news or data being added at this point, it's just RG retelling the exact same story.

And the story includes an application where visible parts of a second are used to construct their pages one very slow request at a time (regardless of what Heroku adds) which is interesting for a lot of us because that's not how many other platforms work.

Post reply on HN