Hacker News Reader

Comment by idlewords | Hacker News Reader

I don't think anyone seriously argues that it's impossible to scale Ruby websites, and make them run quickly with caching and various optimizations.

Rather, the trouble with Ruby (and Rails) is that you end up having to implement these optimizations much faster than with a lighter-weight setup (like PHP on top of a vanilla database, with no ORM).

Hence all the discussion about your "stack", middleware, load-balancing, front-end servers, merbs, mongrels, passengers, and all the bewildering variety of gems required for the care and feeding of a production app. Rails developers write about armoring their app with all this extra stuff in a way reminiscent of MMORPG players equipping a character for battle.

It's a legitimate trade-off, and many people seem comfortable making it. But posts like this sidestep the issue. It's not that Ruby can't scale, is that Ruby makes you fuss over scaling right away.

View on HN

Well, "right away" is kind of misleading. If you're the average company making a Rails website, you'll get by with common-sense optimizations, database indexes and the like that you'd have to do in PHP anyways. I've worked on probably a dozen Rails apps and have only ever had to resort to horizontal scaling and memcached once.

I think the key is that developing the app and scaling the app can be separate tasks. If you do it right, for the lion's share of your app code is still focused on the app, and all the caching and whatnot is handled elsewhere. In PHP, if you had to use memcached it would be a massive change that would touch every corner of your codebase. In Rails, you'd use a plugin and maybe a few filters and you'd be good to go.

I think that's a good description of the tradeoff. At some point, the filters, plugins, middleware and so on that let you focus your energies on the app begin to interact in non-trivial ways, and so the time you spent not having to worry about them during development gets repaid worrying about them in deployment.

That is silly. Why is adding memcached to a PHP app need to be a "massive change that would touch every corner of your codebase"?? Like any web app coded in any language, if it's properly layered, memcached can be added to an app (PHP or not) in a couple lines, sometimes as few as 1 line (ex. ADODB w/ memcached).

Except, the article demonstrates that worrying about scaling right away isn't really necessary (even though it demonstrates how to do so later):

Note that I did not use Mongrel, evented_mongrel, Thin, or anything else sophisticated as the container for the application. It was just webrick, and it was just a single instance of webrick [.. benchmark done here, gets ~35rps ..] OK. I mean, that’s not horrible. Redmine isn’t a lightweight app, and that’s over 2.5 million requests a day on a single process.

Of course, everyone's idea of scaling and what level of requests is reasonable is different, but there are plenty of sites turning over big bucks doing less than 35 requests a second.

Unoptimized Ruby can "do" on modern hardware - even if it's less than ideal. After all, back in the late 90s, even top sites were running on hardware 10-20x times slower than now. So even where Ruby is 10-20x slower than the alternatives, you can still get 1990s enterprise level performance out of it ;-)

So use sinatra if you don't want the complexity of Rails. You seem to be conflating Ruby with Rails.

Does sinatra eliminate or reduce the need for caching, load balancing, and other approaches to handling heavy loads?

To an extent, because it's extremely light. For the simpler kind of webapps, that is.

I don't follow. Sinatra is light because it omits things. Rack is extremely light, too, lighter than Sinatra, but thats obviously because it omits even more things.

If I were to build the same Web site for the same audience and expected traffic using Rails and Sinatra, would using Sinatra (as compared to Rails) reduce the need for what the OP described regarding caching, load balancing, and other methods of increasing performance?

Perhaps it would, as would using Ramaze, or simply writing targeted Rack middleware, but the gains from using lighter tools such as these, as compared to Rails, is that you lose out on using many pre-existing libraries. And while Sinatra and Ramaze are faster than Rails I'm not so sure that they are so much faster that you'd see a big difference in trying to support heavy request loads.

That said I still approach Web apps with the intent of using Ramaze because of it being light, very fast, and feature-complete, but if I find that there are some requirements that are well-matched to some existing Rails extension I'll take that route.

Again, to an extent. If the site is simple enough to do it in Sinatra without too many dependencies, etc., then yes, it would _at least_ postpone performance optimizations.

My understanding is, however, that if the site is already simple, you may wind up not needing to do these improvements in Sinatra.

Maybe reading some discussions about scaling makes you fuss over it right away, but you don't have to.

Initially you can simply install Apache and Passenger (aka. mod_rails). With PHP most people use mod_php.

It is true that hosting rails apps was previously (before passenger) not as easy as mod_php.

With PHP, people discuss "the stack" too. Here's a post about scaling Joomla (written in PHP) discussing using FastCGI instead of mod_php: http://www.joomlaperformance.com/articles/webcasts/why_mod_p...

That's well put.

Half of the article can be reduced to saying that ruby is fast when you don't run it (e.g. through caching), and therefore ruby is fast. That's a fallacy.

Few people care how fast ruby is. They care how fast ruby applications are. Taking caching into account makes sense.

Reply on news.ycombinator.com