[benologist]

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?

[grey-area]

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 your user records at once), this will allocate but then not free lots of memory. Personally I find passenger handles this perfectly well out of the box without having to worry too much about memory usage, routing or other issues, but it does require keeping an eye on the app code as the app grows and fixing any issues that come up with memory usage or response time. Those are not problems specific to rails.

Without knowing the specifics it's hard to say for sure, but I really think RG should try a comparison with running their own real VM (not a web worker on heroku) and see how well it runs. If they'd done that they'd probably find and fix the reasons that their processes are taking so long to respond and taking up such a huge amount of memory, because they'd feel more ownership of those problems, instead of playing a blame game with heroku.

This is not rocket science but it is a series of trade offs and heroku seem to have optimised for short running processes which don't take up lots of memory - many web apps run that way and would be happiest with random routing. Yes heroku could do better but at some point you have to take responsibility for your own ops instead of expecting some service to abstract away all the hard stuff, particularly if you're seeing performance issues and have a busy site. The amount they're paying heroku would easily pay for far more vps than they need.

So in summary, Heroku is not for everyone, and rails isn't really the problem here, so there are no enormous penalties for using it, just the sort of problems you see running any web app.

[PommeDeTerre]

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.

[grey-area]

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.

[dustym]

Rails developers

[seivan]

What kind of bullshit is this? That's 512mb of shared resource, you decide how many requests it actually is.

usually larger rails app can do 2-3 requests on a dyno. Just configure Unicorn workers to that and set it on your procfile. This is known since 2011 (a week after Cedar as announced)

[eridius]

Just configure Unicorn workers to that

Did you bother to read the article before spouting off half-cocked? RG apparently can't even run Unicorn because they don't have enough available memory.

[grk]

Speed and ease of development, mostly.