9 ms·

Why Ruby/Rails speed doesn't matter?

24 points by luccastera 19y ago

deleted 19y ago
[deleted]
tx 19y ago
5 requests/second is "good life average"? While he certainly deserves a credit for trying to shoot conservatively, but such low numbers will only scare more people away. Our slowest requests (with multiple SQL queries and nontrivial rhtml rendering) get served @25-30req/sec, while "regular", i.e. not heavy requests are served @60-120req/sec and we're certainly not "Rails sharks" having less than a year of real life experience and our server is a $850 Opteron box.
- mkull 19y ago
  Just to clarify a bit, he is being conservative, and it's 5 req/sec per mongrel (4 mongrels), which would come out to 20 req/sec for the vps setup.
  - nickb 19y ago
    And you can easily add another slice to this setup... Author definitely has a point. If you're picking a new language for your project, I wouldn't worry about Rails' performance at all.
- fauigerzigerk 19y ago
  Don't forget that he's talking about VPS. Typically a VPS run up to 15 virtual machines on one box.
fauigerzigerk 19y ago
He does have a point. But what still bothers me is that if even a single important part of my app does something computationally expensive (which is typically the case in my apps), I have to interface with C. Writing C code is fine, but the interfacing stuff is no pleasure at all. So I would be glad if Ruby could run, say, 50 times as fast as it does ;-)
- Zak 19y ago
  Might I suggest Common Lisp? SBCL is 50 times as fast as Ruby (standard disclaimer about generic language speed comparisons not being very accurate or meaningful).
  - fauigerzigerk 19y ago
    Is there a reasonably mature web framework for SBCL?
    - Zak 19y ago
      There are a number of tools available for making web applications using Common Lisp. Most or all work well on SBCL. I don't think any are as mature as Rails. Most Lispers don't take the all-in-one approach of Rails - they're more likely to use a collection of libraries than a framework. Some tools to look at are Hunchentoot, CL-WHO, HTML-template, Weblocks, Uncommonweb, CLSQL and Kpax.
jawngee 19y ago
I wrote this as a response, but it's awaiting moderation: I think this article is pretty irresponsible. Your making some weak excuses for Ruby's poor performance that, frankly, speaks more about your laziness as a developer than it does about Ruby. One just needs to point at Friendster for an example of what happens when your application is too slow at the wrong time. When Friendster started hitting it big, a long time ago, they couldn't deal with the load and they lost a lot of marketshare because of it. On top of it, they undertook a huge effort to rewrite it in something faster, but it was too little too late. Furthermore, when application availability is crucial to the success of your application, you had better be thinking about performance well before it becomes a problem. Throwing more "metal" at the problem isn't a solution, and you even point it out in your article, "if you can't afford a cluster of Opterons just yet, you're just using some average VPS slice and you're on a tight budget for the first month". Well, if you're on a tight budget how are you going to afford that extra metal to throw at it? "Good enough" doesn't cut it, and if I'm an investor in your company and the first spike in traffic nearly kills the application and we lose market because of it, well your laziness is going to be the first thing I evaluate. Note that I'm not promoting any language in response, because it's not really a language issue. Anything you bring to bear on the public, performance should be a primary concern. As a CTO in a company, it's my chief concern, to be honest. An ounce of prevention ...
davidw 19y ago
I'm a big Rails fan, and have pretty much been using it exclusively lately. However, I've been around the block enough times to know someone trying to cover for a language's weak points when I see it. I think the honest analysis is: "When considering all the tradeoffs in creating something, the slow speed is not a deal breaker for the kind of app I'm writing. On the plus side, I get something that's very fast to write apps with, a big, helpful, smart community, and the prospect of a faster language in the future".
cstejerean 19y ago
well, as long as the choice is between ruby and python I don't really care. Each has its strengths and weaknesses but they are both pleasant language to write things in. Developer time is worth more than CPU time but I think that Python and Ruby would have to be at about the same level in terms of developer productivity (I use both Python and Ruby but I use Python a lot more than Ruby so maybe there is some Ruby magic that I'm not aware of that would make it MUCH more productive).
jamiequint 19y ago
It would be awesome if the hits on your site were spread out completely evenly over the course of a month, yet when is that ever the case. Say you were to get dugg, I have to imagine that at a concurrency rate of only 20 reqs/sec your site would probably go down.

24 points by luccastera 19y ago

deleted 19y ago

[deleted]

tx 19y ago

5 requests/second is "good life average"? While he certainly deserves a credit for trying to shoot conservatively, but such low numbers will only scare more people away. Our slowest requests (with multiple SQL queries and nontrivial rhtml rendering) get served @25-30req/sec, while "regular", i.e. not heavy requests are served @60-120req/sec and we're certainly not "Rails sharks" having less than a year of real life experience and our server is a $850 Opteron box.

mkull 19y ago
Just to clarify a bit, he is being conservative, and it's 5 req/sec per mongrel (4 mongrels), which would come out to 20 req/sec for the vps setup.
- nickb 19y ago
  And you can easily add another slice to this setup... Author definitely has a point. If you're picking a new language for your project, I wouldn't worry about Rails' performance at all.
fauigerzigerk 19y ago
Don't forget that he's talking about VPS. Typically a VPS run up to 15 virtual machines on one box.

fauigerzigerk 19y ago

He does have a point. But what still bothers me is that if even a single important part of my app does something computationally expensive (which is typically the case in my apps), I have to interface with C. Writing C code is fine, but the interfacing stuff is no pleasure at all. So I would be glad if Ruby could run, say, 50 times as fast as it does ;-)

Zak 19y ago
Might I suggest Common Lisp? SBCL is 50 times as fast as Ruby (standard disclaimer about generic language speed comparisons not being very accurate or meaningful).
- fauigerzigerk 19y ago
  Is there a reasonably mature web framework for SBCL?
  - Zak 19y ago
    There are a number of tools available for making web applications using Common Lisp. Most or all work well on SBCL. I don't think any are as mature as Rails. Most Lispers don't take the all-in-one approach of Rails - they're more likely to use a collection of libraries than a framework. Some tools to look at are Hunchentoot, CL-WHO, HTML-template, Weblocks, Uncommonweb, CLSQL and Kpax.

jawngee 19y ago

I wrote this as a response, but it's awaiting moderation: I think this article is pretty irresponsible. Your making some weak excuses for Ruby's poor performance that, frankly, speaks more about your laziness as a developer than it does about Ruby. One just needs to point at Friendster for an example of what happens when your application is too slow at the wrong time. When Friendster started hitting it big, a long time ago, they couldn't deal with the load and they lost a lot of marketshare because of it. On top of it, they undertook a huge effort to rewrite it in something faster, but it was too little too late. Furthermore, when application availability is crucial to the success of your application, you had better be thinking about performance well before it becomes a problem. Throwing more "metal" at the problem isn't a solution, and you even point it out in your article, "if you can't afford a cluster of Opterons just yet, you're just using some average VPS slice and you're on a tight budget for the first month". Well, if you're on a tight budget how are you going to afford that extra metal to throw at it? "Good enough" doesn't cut it, and if I'm an investor in your company and the first spike in traffic nearly kills the application and we lose market because of it, well your laziness is going to be the first thing I evaluate. Note that I'm not promoting any language in response, because it's not really a language issue. Anything you bring to bear on the public, performance should be a primary concern. As a CTO in a company, it's my chief concern, to be honest. An ounce of prevention ...

davidw 19y ago

I'm a big Rails fan, and have pretty much been using it exclusively lately. However, I've been around the block enough times to know someone trying to cover for a language's weak points when I see it. I think the honest analysis is: "When considering all the tradeoffs in creating something, the slow speed is not a deal breaker for the kind of app I'm writing. On the plus side, I get something that's very fast to write apps with, a big, helpful, smart community, and the prospect of a faster language in the future".

cstejerean 19y ago

well, as long as the choice is between ruby and python I don't really care. Each has its strengths and weaknesses but they are both pleasant language to write things in. Developer time is worth more than CPU time but I think that Python and Ruby would have to be at about the same level in terms of developer productivity (I use both Python and Ruby but I use Python a lot more than Ruby so maybe there is some Ruby magic that I'm not aware of that would make it MUCH more productive).

jamiequint 19y ago

It would be awesome if the hits on your site were spread out completely evenly over the course of a month, yet when is that ever the case. Say you were to get dugg, I have to imagine that at a concurrency rate of only 20 reqs/sec your site would probably go down.