Cost of scaling Rails vs cost of scaling PHP vs Python frameworks

Question

I guess this question has been asked a lot around. I know Rails can scale because I have worked on it and it's awesome. And there is not much doubt about that as far as PHP frameworks are concerned.

I don't want to know which frameworks are better.

How much is difference in cost of scaling Rails vs other frameworks (PHP, Python) assuming a large app with 1 million visits per month?

This is something I get asked a lot. I can explain to people that "Rails does scale pretty well" but in the long run, what are the economics?

If somebody can provide some metrics, that'd be great.

Answer 1

One major factor in this is that isn't affected by choice of framework is database access. No matter what approach you take, you likely put data in a relational database. Then the question is how efficiently you can get the data out of the database. This primarily depends on the RDBMS (Oracle vs. Postgres vs. MySQL), and not on the framework - except that some data mapping library may make inefficient use of SQL.

For the pure "number of visits" parameter, the question really is how fast your HTML templating system works. So the question is: how many pages can you render per second? I would make this the primary metrics to determine how good a system would scale.

Of course, different pages may have different costs; for some, you can use caching, but not for others. So in measuring scalability, split your 1 million visits into cheap and expensive pages, and measure them separately. Together, they should give a good estimate of the load your system can take (or the number of systems you need to satisfy demand).

There is also the issue of memory usage. If you have the data in SQL, this shouldn't matter - but with caching, you may also need to consider scalability wrt. main memory usage.

Answer 2

IMHO I don't think the cost of scaling is going to be any different between those three because none of them have "scalability batteries" included. I just don't see any huge architectural differences between those three choices that would cause a significant difference in scaling.

In other words, your application architecture is going to dominate how the application scales regardless of which of the three languages.

If you need memory caching you're going to at least use memcached (or something similar which will interface with all three languages). Maybe you help your scalability using nginx to serve directly from memcache, but that's obviously not going to change the performance of php/perl/python/ruby.

If you use MySQL or Postgresql you're still going to have to design your database correctly for scaling regardless of your app language, and any tool you use to start clustering / mirroring is going to be outside of your app.

I think in terms of memory usage Python (with mod_wsgi daemon mode) and Ruby (enterprise ruby with passenger/mod_rack) have pretty decent footprints at least comparable to PHP under fcgi and probably better than PHP under mod_php (i.e. apache MPM prefork + php in all the apache processes sucks a lot of memory).

Where this question might be interesting is trying to compare those 3 languages vs. something like Erlang where you (supposedly) have cheap built-in scalability automatically in all Erlang processes, but even then you'll have a RDBMS database bottleneck unless your app nicely fits into one of the Erlang database ways of doing things, e.g. couchdb.