4 ms·

Rails is plenty fast - for application development. And a well-designed rails app, appropriately tuned, can be suitable for all but the highest volume loads. T

by enko 13y ago

Rails is plenty fast - for application development. And a well-designed rails app, appropriately tuned, can be suitable for all but the highest volume loads. This rails bashing is becoming a cliché, so here's another one - use the right tool for the job. I've worked on rails projects happily serving 100req/sec with the servers running at 20% load. I've got friends who work on J2EE sites which take 10 seconds to render a page after the app server's done talking to all its zillion little useless ESB friends. Is ruby faster than compiled java? I currently work on a combined rails/node site - we use a rails API to feed a node-served front end. Works beautifully. Why is the API using rails? Because in my opinion, rails is far more mature, and one rails API dev can keep up with three node front end devs. Would the decision be the same if speed and efficiency on the server was of topmost priority? Probably not, but it wasn't. Hell, the DB is the performance bottleneck anyway. I have nothing against node and will probably use it in an upcoming project where server effiency is the topmost priority but geeze, right tool for the job! And another point, while I'm ranting - I am coming to see node as the obvious choice for consumer (free) and rails as the obvious choice for B2B/SAAS (paid). Why? Because hyper-effiency is much more important for the former to keep cost per user down. With B2B, if you've got so many paying customers you need another rails server, you throw a party! Oh, and even the node devs I know deploy using capistrano. There's that right tool for the job thing again.

usethis 13y ago
Thanks for the reply. This is almost exactly what I wanted to write, especially in terms of programming costs of Rails vs. nodejs. I am working on a project with exactly the same setup now, Rails for the API and a NodeJS Proxy for the web – works beautifully and with the mature ecosystem around Rails, development of the API has been very easy and focused. Much of the critique regarding the slowness of Rails relates to earlier versions of both Rails and Ruby, but nowadays it can match the most mature frameworks.
KaiserPro 13y ago
Rails is fast, if you've never dealt with anything in HPC. Also I was more referencing that if you rebuild an app you expect it to be faster. However: 100 Requests a second and at 20% CPU. Really!? Considering basically all rails/node.js/php/etc apps do is add frilly bits to data held in a database, there is no real reason why it should be slow. To put it into context, say you are serving a home page, its maybe 150k of HTML/JS of which 90% of it is the same regardless of who visits the page. (hence why proxies are so effective) Thats 15Megs a second. Not exactly Uber fast, considering its effectively a dumbarse file server. To put it in context, your standard linux fileserver will (over NFS) push out 1.1gigabyte a second at 30% CPU (assuming disks allow) From a ZFS file system (which is computing the checksums of each 4k block....) so yes, rails is slow.
- enko 13y ago
  You know, when we say "X is fast/slow" we usually are basing the comparison on something even remotely related. If we don't do that, the comparison is basically useless. Of course rails, and almost any other software, is "slow" compared to HPC. I struggle to name two less similar applications. You might as well say that aircraft carriers are slow compared to F16s - well yes, yes they are. The rest of your comment indicates to me you have no experience with web programming. Of course the cacheable parts are simply read from a disk, or even memory. It's the uncacheable parts that are the problem. And no, it's not just "adding frilly bits to data held in a database". You seem to have a bad case of "shit's easy syndrome" - the tendency of people who have no idea what they're talking about to assume that everything is easy, and anyone who disagrees must simply be stupid or at least incompetent. Well, if you can build a web framework that's as productive to use as rails but works 100x faster, you will be a millionaire practically overnight. Have at it. Forgive me if I don't hold my breath.
  - KaiserPro 13y ago
    Oh but it really is adding frilly bits to data. Have a good long hard look at the data flow of your web app. Take for example a CMS: A user comes along, the web page is generated, The data comes from a database, its encapsulated in HTML/JSON/x and then sent to the client. (either all at once or chopped up into bits and done asynchronously). If you're advanced, you might pull data from an API (still repacking data in a veneer of *ML) I have a case of "shits already done" syndrome. For 99% of companies any old web framework will do. Those 1% that need a bit extra, spend the man hours on engineering ways round the deficiencies in the framework they chose. Most of that effort goes into expanding the namespace of the database, Because IO is a pain at scale. I work in VFX where efficiency and scale really matter. I look after 16k cores and ~5+pb of tier 1 disk storage. 1% increase of efficiency in CPU usage is worth heafty cash. I've seen many, many fads. (Map+reduce, rails, mongodb, couchdb) All of them are re-inventions of the wheel (Map+reduce was seen as a task dispatching system, Rails was supposedly going to replace QT, Mongo/couchdb was supposedly going to replace a posix file system, and postgres as well) We're now back at the stage where Postgres +SQL is awesome, Filesystems are good at storing unstructured data, and pythonQT really isn't that scary after all. Although node.js and callbacks are starting to become popular now.....

by enko 13y ago

usethis 13y ago

Thanks for the reply. This is almost exactly what I wanted to write, especially in terms of programming costs of Rails vs. nodejs. I am working on a project with exactly the same setup now, Rails for the API and a NodeJS Proxy for the web – works beautifully and with the mature ecosystem around Rails, development of the API has been very easy and focused. Much of the critique regarding the slowness of Rails relates to earlier versions of both Rails and Ruby, but nowadays it can match the most mature frameworks.

KaiserPro 13y ago

Rails is fast, if you've never dealt with anything in HPC. Also I was more referencing that if you rebuild an app you expect it to be faster. However: 100 Requests a second and at 20% CPU. Really!? Considering basically all rails/node.js/php/etc apps do is add frilly bits to data held in a database, there is no real reason why it should be slow. To put it into context, say you are serving a home page, its maybe 150k of HTML/JS of which 90% of it is the same regardless of who visits the page. (hence why proxies are so effective) Thats 15Megs a second. Not exactly Uber fast, considering its effectively a dumbarse file server. To put it in context, your standard linux fileserver will (over NFS) push out 1.1gigabyte a second at 30% CPU (assuming disks allow) From a ZFS file system (which is computing the checksums of each 4k block....) so yes, rails is slow.

enko 13y ago
You know, when we say "X is fast/slow" we usually are basing the comparison on something even remotely related. If we don't do that, the comparison is basically useless. Of course rails, and almost any other software, is "slow" compared to HPC. I struggle to name two less similar applications. You might as well say that aircraft carriers are slow compared to F16s - well yes, yes they are. The rest of your comment indicates to me you have no experience with web programming. Of course the cacheable parts are simply read from a disk, or even memory. It's the uncacheable parts that are the problem. And no, it's not just "adding frilly bits to data held in a database". You seem to have a bad case of "shit's easy syndrome" - the tendency of people who have no idea what they're talking about to assume that everything is easy, and anyone who disagrees must simply be stupid or at least incompetent. Well, if you can build a web framework that's as productive to use as rails but works 100x faster, you will be a millionaire practically overnight. Have at it. Forgive me if I don't hold my breath.
- KaiserPro 13y ago
  Oh but it really is adding frilly bits to data. Have a good long hard look at the data flow of your web app. Take for example a CMS: A user comes along, the web page is generated, The data comes from a database, its encapsulated in HTML/JSON/x and then sent to the client. (either all at once or chopped up into bits and done asynchronously). If you're advanced, you might pull data from an API (still repacking data in a veneer of *ML) I have a case of "shits already done" syndrome. For 99% of companies any old web framework will do. Those 1% that need a bit extra, spend the man hours on engineering ways round the deficiencies in the framework they chose. Most of that effort goes into expanding the namespace of the database, Because IO is a pain at scale. I work in VFX where efficiency and scale really matter. I look after 16k cores and ~5+pb of tier 1 disk storage. 1% increase of efficiency in CPU usage is worth heafty cash. I've seen many, many fads. (Map+reduce, rails, mongodb, couchdb) All of them are re-inventions of the wheel (Map+reduce was seen as a task dispatching system, Rails was supposedly going to replace QT, Mongo/couchdb was supposedly going to replace a posix file system, and postgres as well) We're now back at the stage where Postgres +SQL is awesome, Filesystems are good at storing unstructured data, and pythonQT really isn't that scary after all. Although node.js and callbacks are starting to become popular now.....