In an interview with RadicalBehavior.com, Twitter lead developer Alex Payne commented [radicalbehavior.com]:
By various metrics Twitter is the biggest Rails site on the net right now. Running on Rails has forced us to deal with scaling issues - issues that any growing site eventually contends with - far sooner than I think we would on another framework. [...] At this point in time there's no facility in Rails to talk to more than one database at a time. [...] All the convenience methods and syntactical sugar that makes Rails such
Running on Rails has forced us to deal with scaling issues - issues that any growing site eventually contends with - far sooner than I think we would on another framework.
That is probably true. However, I would count that as an advantage -- better to deal with them sooner than later.
At this point in time there's no facility in Rails to talk to more than one database at a time.
There are many, many ways to talk to more than one database in Rails. In fact, it is possible to swap out the entire database layer of Rails and use another ORM, or no ORM at all. On the bleeding edge -- and Twitter might actually be a good candidate for this -- people have wired up Rails to CouchDB, which provides trivially scalable multimaster replication, and which, being HTTP, can be thrown behind any old load balancer -- which brings this back to a "just throw hardware at it" problem.
All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise.
Some of them do -- a good example would be Symbol.to_proc.
However, Merb proves that this is not actually a Ruby problem, it is a Rails problem. And Rails and Merb are merging some point in the near future.
It's also worth mentioning that there shouldn't be doubt in anybody's mind at this point that Ruby itself is slow. [...] I think it's worth being frank that this isn't one of those relativistic language issues. Ruby is slow.
Somewhat true -- after all, Ruby 1.9.1 did double the performance of the language.
But, relative to what?
Turns out that, at least compared to other languages and frameworks (like PHP), Ruby is not slow [slideshare.net].
It's also worth mentioning that while all of the Twitter alternatives may have enjoyed better uptime, they haven't had nearly the amount of traffic that Twitter does. We don't really know if they can scale -- but even supposing they can, Twitter was there first. And while they complain about those nice features being slow, they probably owe their success to those features for getting their product out the door faster than their competitors.
It's also worth mentioning that this interview is almost two years old. Rails changes a lot in two years. In fact, Twitter were early adopters -- two years before that interview, Rails had only just shared commit rights. Two years before that, it didn't exist at all.
It might be worth asking what version of Rails Twitter is using, and if they've noticed a change since then.
Actually, compared to PHP, it is slow. Alot of people benchmark PHP incorrectly. Everyone who knows anything about PHP knows it was built to be an Apache module and never to be used as a command line utility because it doesn't have a daemon; it doesn't run in the background like other languages, it starts up and shuts down after running each script.
This is why if you don't benchmark it as an Apache module (where it IS running as a daemon), it loses a second or two in the benchmark while it starts up its
Actually, compared to PHP, it is slow. Alot of people benchmark PHP incorrectly. Everyone who knows anything about PHP knows it was built to be an Apache module and never to be used as a command line utility because it doesn't have a daemon
Then you might be surprised by the benchmark I actually linked to. This was a measure in requests per second of a full Web application, not of something silly like fibbonacci.
Nuby developers love to quote this stat but are clueless in the fact that what they are quoting is completely wrong.
Once again: Look at the actual statistic I'm quoting. Are you suggesting this was CakePHP, run as a web app, benchmarked with a web benchmark, yet somehow run as a commandline app?
Once again: Look at the actual statistic I'm quoting. Are you suggesting this was CakePHP, run as a web app, benchmarked with a web benchmark, yet somehow run as a commandline app?
I've never used CakePHP before, but every benchmark I find on it suggests that it's horribly slower (10-100x slower, if not more) than stock PHP. For example, over here [sellersrank.com] they get 37.46 requests/s for a hello world CakePHP page on a 3 GHz Intel machine with 512M RAM. I gave a plain PHP hello world page a try on a 1.3 GHz Pentium-M l
they get 37.46 requests/s for a hello world CakePHP page on a 3 GHz Intel machine with 512M RAM. I gave a plain PHP hello world page a try on a 1.3 GHz Pentium-M laptop
How much does either of those have to do with the real world? That's why I linked to a benchmark of a real (though simple) app, that actually reads and writes to a database...
I mean, I'm sure I can beat your scores with a static page.
What matters is, when you actually start to build out your application's logic, how much do you have to rewrite yourself that you could have borrowed from something like Cake? Are you sure you're doing it more efficiently than Cake would be?
They have tons to do with the real world. It means that, as a baseline, the machine in that benchmark will never run a CakePHP application faster than ~37 requests/s, which is pretty bloody slow.
Will a full fledged PHP app be slower than a hello world CakePHP app? Not even close, at least in my experience. For example, Game! [wittyrpg.com] runs in excess of 100 requests/s on the very modest hardware I mentioned above, and would likely be well over 300 requests/s on the 3 GHz machine in the benchmark I linked (assuming it'
The point of my post is that comparing to CakePHP is a lousy comparison, because a) CakePHP is a pretty minor player in the PHP world, and b) CakePHP is hideously slow.
Point b, I could have made about Rails -- and it's still not as slow as you would think.
Since I can't get people to actually watch the presentation, let me quote from it:
331 requests per second in a raw PHP app. Static HTML was 1327 rps.
Cake was barely 8, with acceleration.
Ruby, with a single mongrel, was 85 rps. With Passenger and Enterprise Ruby, 96 rps. So already, Rails is close enough that, worst case, you would have to run it on two machines instead of one.
That benchmark is useless. You are comparing an apple to an orange. We were talking about RUBY not RUBY+RAILS vs PHP+CakePHP(bloat). And CakePHP is known to be one of the slowest frameworks [phpulse.com] for PHP. A real benchmark would at least compare the same code (Yes, like a Fibonnacci) to test how the LANGUAGE and not the FRAMEWORK benchmarks.
Come back when you understand how benchmarks work Nuby.
We were talking about RUBY not RUBY+RAILS vs PHP+CakePHP(bloat).
In that case, you might be interested in the examples using the Merb router, which is actually comparable to static content. This was compared to raw PHP, both with echo and with templates.
A real benchmark would at least compare the same code (Yes, like a Fibonnacci) to test how the LANGUAGE and not the FRAMEWORK benchmarks.
A Fibonacci is irrelevant -- when was the last time you used a Fibonacci in a commercial app?
These benchmarks are testing a real app. If that app ends up being written differently in the different languages, I would suggest that this is not necessarily bias, but quite possibly that one language lends itself to cleaner and
Then sadly, you understand little about benchmarks. I could benchmark Microsoft Office against a Hello World app written in Perl too. Does it mean anything? It means the same as the benchmarks you pointed to. Because too much is going on in the backend to know what precisely you are benchmarking. This is WHY benchmarks are done wtih things like the fibonacci sequence... duh.
Seriously, you'll learn this when you get out of high school.
Well said sir. Scaling is not about language opcode execution speed. Apps don't scale by eliminating a few JMPs and BEQs here and there. Instead, they scale by coming up with good _architectures_. Caching, partitioning, sharding, queuing, backgrounding... all that stuff. Given a good enough architect you could probably write EBay in Bash.
Not that those things are irrelevant, just that initially, they are less important.
Certainly, it's possible eBay could save a lot of money on hardware by rewriting the site in a faster language (or even in C) if they started in Bash. It's also possible they would start looking at other optimizations -- all those little hacks you avoid during development could suddenly mean thousands of dollars saved.
But you won't know which hacks are worth thousands of dollars, and which ones will cause thousands of dollars
> all those little hacks you avoid during > development could suddenly mean thousands of dollars saved
Yeah, that's the stuff I'm thinking of. "We won't generate this on the fly, we'll put it in a queue and process the queue every 5 seconds." "We won't immediately write this to all the servers, instead we'll rsync it up in a batch job." I wouldn't even call those "little hacks"... I'd say that those are architecture decisions that you make once you realize you need them. And, as you say, until you n
The price one pays for pursuing any profession, or calling, is an intimate
knowledge of its ugly side. -- James Baldwin
Twitter Developer Alex Payne on Rails performance (Score:5, Interesting)
Re:Twitter Developer Alex Payne on Rails performan (Score:4, Informative)
Running on Rails has forced us to deal with scaling issues - issues that any growing site eventually contends with - far sooner than I think we would on another framework.
That is probably true. However, I would count that as an advantage -- better to deal with them sooner than later.
At this point in time there's no facility in Rails to talk to more than one database at a time.
There are many, many ways to talk to more than one database in Rails. In fact, it is possible to swap out the entire database layer of Rails and use another ORM, or no ORM at all. On the bleeding edge -- and Twitter might actually be a good candidate for this -- people have wired up Rails to CouchDB, which provides trivially scalable multimaster replication, and which, being HTTP, can be thrown behind any old load balancer -- which brings this back to a "just throw hardware at it" problem.
All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise.
Some of them do -- a good example would be Symbol.to_proc.
However, Merb proves that this is not actually a Ruby problem, it is a Rails problem. And Rails and Merb are merging some point in the near future.
It's also worth mentioning that there shouldn't be doubt in anybody's mind at this point that Ruby itself is slow. [...] I think it's worth being frank that this isn't one of those relativistic language issues. Ruby is slow.
Somewhat true -- after all, Ruby 1.9.1 did double the performance of the language.
But, relative to what?
Turns out that, at least compared to other languages and frameworks (like PHP), Ruby is not slow [slideshare.net].
It's also worth mentioning that while all of the Twitter alternatives may have enjoyed better uptime, they haven't had nearly the amount of traffic that Twitter does. We don't really know if they can scale -- but even supposing they can, Twitter was there first. And while they complain about those nice features being slow, they probably owe their success to those features for getting their product out the door faster than their competitors.
It's also worth mentioning that this interview is almost two years old. Rails changes a lot in two years. In fact, Twitter were early adopters -- two years before that interview, Rails had only just shared commit rights. Two years before that, it didn't exist at all.
It might be worth asking what version of Rails Twitter is using, and if they've noticed a change since then.
Re: (Score:1)
This is why if you don't benchmark it as an Apache module (where it IS running as a daemon), it loses a second or two in the benchmark while it starts up its
Re: (Score:2)
Actually, compared to PHP, it is slow. Alot of people benchmark PHP incorrectly. Everyone who knows anything about PHP knows it was built to be an Apache module and never to be used as a command line utility because it doesn't have a daemon
Then you might be surprised by the benchmark I actually linked to. This was a measure in requests per second of a full Web application, not of something silly like fibbonacci.
Nuby developers love to quote this stat but are clueless in the fact that what they are quoting is completely wrong.
Once again: Look at the actual statistic I'm quoting. Are you suggesting this was CakePHP, run as a web app, benchmarked with a web benchmark, yet somehow run as a commandline app?
Re: (Score:3, Interesting)
I've never used CakePHP before, but every benchmark I find on it suggests that it's horribly slower (10-100x slower, if not more) than stock PHP. For example, over here [sellersrank.com] they get 37.46 requests/s for a hello world CakePHP page on a 3 GHz Intel machine with 512M RAM. I gave a plain PHP hello world page a try on a 1.3 GHz Pentium-M l
Re: (Score:2)
they get 37.46 requests/s for a hello world CakePHP page on a 3 GHz Intel machine with 512M RAM. I gave a plain PHP hello world page a try on a 1.3 GHz Pentium-M laptop
How much does either of those have to do with the real world? That's why I linked to a benchmark of a real (though simple) app, that actually reads and writes to a database...
I mean, I'm sure I can beat your scores with a static page.
What matters is, when you actually start to build out your application's logic, how much do you have to rewrite yourself that you could have borrowed from something like Cake? Are you sure you're doing it more efficiently than Cake would be?
By the time you've built your own rou
Re: (Score:2)
They have tons to do with the real world. It means that, as a baseline, the machine in that benchmark will never run a CakePHP application faster than ~37 requests/s, which is pretty bloody slow.
Will a full fledged PHP app be slower than a hello world CakePHP app? Not even close, at least in my experience. For example, Game! [wittyrpg.com] runs in excess of 100 requests/s on the very modest hardware I mentioned above, and would likely be well over 300 requests/s on the 3 GHz machine in the benchmark I linked (assuming it'
Re: (Score:2)
The point of my post is that comparing to CakePHP is a lousy comparison, because a) CakePHP is a pretty minor player in the PHP world, and b) CakePHP is hideously slow.
Point b, I could have made about Rails -- and it's still not as slow as you would think.
Since I can't get people to actually watch the presentation, let me quote from it:
331 requests per second in a raw PHP app. Static HTML was 1327 rps.
Cake was barely 8, with acceleration.
Ruby, with a single mongrel, was 85 rps. With Passenger and Enterprise Ruby, 96 rps. So already, Rails is close enough that, worst case, you would have to run it on two machines instead of one.
Merb, with templates, was over a thousand rps
Re: (Score:2)
Come back when you understand how benchmarks work Nuby.
Re: (Score:2)
We were talking about RUBY not RUBY+RAILS vs PHP+CakePHP(bloat).
In that case, you might be interested in the examples using the Merb router, which is actually comparable to static content. This was compared to raw PHP, both with echo and with templates.
A real benchmark would at least compare the same code (Yes, like a Fibonnacci) to test how the LANGUAGE and not the FRAMEWORK benchmarks.
A Fibonacci is irrelevant -- when was the last time you used a Fibonacci in a commercial app?
These benchmarks are testing a real app. If that app ends up being written differently in the different languages, I would suggest that this is not necessarily bias, but quite possibly that one language lends itself to cleaner and
Re: (Score:2)
Seriously, you'll learn this when you get out of high school.
Re: (Score:2)
I could benchmark Microsoft Office against a Hello World app written in Perl too.
Which is why it was Merb Router vs Raw PHP. More like Hello World in Ruby vs Hello World in Perl.
Except, of course, benchmarking Hello World is as irrelevant as benchmarking fibonacci.
Because too much is going on in the backend to know what precisely you are benchmarking.
Except that this is the same stuff that will be going on in the backend in a real app.
In other words, these are benchmarks of stuff that matter.
Seriously, you'll learn this when you get out of high school.
Has it occurred to you that I might know this from practical experience, designing real applications?
Nah, couldn't be. Obviously, I must be a high school kid, who knows nothing about t
Re: (Score:2)
Re: (Score:2)
> better to deal with them sooner than later.
Well said sir. Scaling is not about language opcode execution speed. Apps don't scale by eliminating a few JMPs and BEQs here and there. Instead, they scale by coming up with good _architectures_. Caching, partitioning, sharding, queuing, backgrounding... all that stuff. Given a good enough architect you could probably write EBay in Bash.
Re: (Score:2)
Not that those things are irrelevant, just that initially, they are less important.
Certainly, it's possible eBay could save a lot of money on hardware by rewriting the site in a faster language (or even in C) if they started in Bash. It's also possible they would start looking at other optimizations -- all those little hacks you avoid during development could suddenly mean thousands of dollars saved.
But you won't know which hacks are worth thousands of dollars, and which ones will cause thousands of dollars
Re: (Score:1)
> all those little hacks you avoid during
> development could suddenly mean thousands of dollars saved
Yeah, that's the stuff I'm thinking of. "We won't generate this on the fly, we'll put it in a queue and process the queue every 5 seconds." "We won't immediately write this to all the servers, instead we'll rsync it up in a batch job." I wouldn't even call those "little hacks"... I'd say that those are architecture decisions that you make once you realize you need them. And, as you say, until you n