5 ms·

Neither matter, what matters is profitability. It doesn't matter if you can serve 10,000 requests per second if the cost of that request exceeds what you're pa

by fleitz 16y ago

Neither matter, what matters is profitability. It doesn't matter if you can serve 10,000 requests per second if the cost of that request exceeds what you're paid for it. For most sites ruby is profitable, the value add from ruby is decreased cycle time between releases which can increase the profitability of your site more than increasing the pages per second can. The vast majority of sites don't need to scale beyond a single server, and when you do need to scale I prefer things like drop in support for S3, drop in support for memcached and a whole host of other performance increasing techniques over raw pages per second. The benchmark benchmarks the very simple case of a single PHP page, what real PHP app have you used that is a single PHP page? The request times for something like WordPress are insane because of the number of PHP files that need to be interpreted per request. edit: To clarify the jist is that low margin activities where increasing the speed of your page by 5X would have a great impact on your profitability are not the areas where you should focus you efforts. Instead focus on high margin areas where you could write your pages in SnailScript and you'd still be profitable.

eli 16y ago
Studies have shown that people convert better and view more pages if a site is faster [1]. And page load speed is a factor in your Google ranking [2]. [1] http://www.watchingwebsites.com/archives/proof-that-speeding-up-websites-improves-online-business/ http://www.watchingwebsites.com/archives/proof-that-speeding... [2] http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html http://googlewebmastercentral.blogspot.com/2010/04/using-sit...
- fleitz 16y ago
  That's all well and true but honestly, how many currently unprofitable sites would become monstrously profitable if they could increase their requests per second by a factor of 5? The study you link to shows a decrease of in rev of 5% by adding 2 seconds of load time vs. 50 ms. There are very few businesses whose costs are dominated by servers. Most spend more on a single developer than servers. Yes, Google, Twitter, and Facebook could probably do well by doubling their requests per second but the average companies costs are dominated by employees, that why it's called Ramen profitable and not EC2 Micro profitable.
  - eli 16y ago
    No need to put words in my mouth. There are no magic bullets to monstrous profitability. But website speed is one of those things (among many others!) that has a measurable impact on your business. This isn't just a nerdy pissing contest.
davidu 16y ago
1) AMZN and GOOG have proven that pageload speed does in fact directly relate to profitability. 2) Regarding "The vast majority of sites don't need to scale beyond a single server," you could make the same point that the vast majority of sites are not profitable either. It's a total non sequitur in either case. 3) Your point that it "costs less" to develop in Ruby which can increase the profitability of your site is an incorrect assertion. It may be true that the time to develop in ruby can decrease your R&D costs, it does not affect your cost of goods sold and has no impact on your margins. If you just say "it costs me $100 less to develop in ruby, thus I've made an extra $100" you need to take an accounting course. More to the point, if you are building your business with your optimization being focused on decreasing development time, you have already lost sight of the goal. PHP sucks, but there are a ton of profitable companies that use it because it is wicked wicked fast. In my mind, that makes it suck less. :-) -David
- davidw 16y ago
  > PHP sucks, but there are a ton of profitable companies that use it because it is wicked wicked fast. In my mind, that makes it suck less. :-) I think in this mini benchmark, it's not so much that "PHP" is fast (as a language, it isn't, really), rather that Ruby + its various frameworks are pretty pokey. In any case though, while I remain a Ruby fan, the grandparent sort of misses the point: by being more efficient, you have a wider range of things that can make you money. If you have to have a huge amount of resources to get some pages up, doing ads or some other low-margin activity might not even be feasible like it would with a faster solution.
  - fleitz 16y ago
    You're actually on to my point which is to stop doing low margin activities and focus on high margin activities. Low margin activities are where writing a page in C / C++ might be a really good idea. The performance critical parts of your site can always be rewritten in assembler if need be. If your margin on a page request is 5% your business is probably fucked anyway (unless your serving billions of pageviews per month, there are only a few sites that work on this business model). I'd much rather have a business with orders of magnitude fewer requests and a profit margin on the order of 10s of thousands per page request. What do you think 37Signals margin on a page request for basecamp is? My guess is at least 10,000%.
antirez 16y ago
There is nothing in 99% of Ruby slowness culture that is due to optimizing for the programmer IMHO. It is just the missing profiling step or the right design to be fast most of the times. So many things can be improved without killing any abstraction opportunity. On the other side, profitable or not, users don't like to wait that 200 milliseconds more because the code is not written in the right way.

by fleitz 16y ago

eli 16y ago

Studies have shown that people convert better and view more pages if a site is faster [1]. And page load speed is a factor in your Google ranking [2]. [1] http://www.watchingwebsites.com/archives/proof-that-speeding-up-websites-improves-online-business/ http://www.watchingwebsites.com/archives/proof-that-speeding... [2] http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html http://googlewebmastercentral.blogspot.com/2010/04/using-sit...

fleitz 16y ago
That's all well and true but honestly, how many currently unprofitable sites would become monstrously profitable if they could increase their requests per second by a factor of 5? The study you link to shows a decrease of in rev of 5% by adding 2 seconds of load time vs. 50 ms. There are very few businesses whose costs are dominated by servers. Most spend more on a single developer than servers. Yes, Google, Twitter, and Facebook could probably do well by doubling their requests per second but the average companies costs are dominated by employees, that why it's called Ramen profitable and not EC2 Micro profitable.
- eli 16y ago
  No need to put words in my mouth. There are no magic bullets to monstrous profitability. But website speed is one of those things (among many others!) that has a measurable impact on your business. This isn't just a nerdy pissing contest.

davidu 16y ago

1) AMZN and GOOG have proven that pageload speed does in fact directly relate to profitability. 2) Regarding "The vast majority of sites don't need to scale beyond a single server," you could make the same point that the vast majority of sites are not profitable either. It's a total non sequitur in either case. 3) Your point that it "costs less" to develop in Ruby which can increase the profitability of your site is an incorrect assertion. It may be true that the time to develop in ruby can decrease your R&D costs, it does not affect your cost of goods sold and has no impact on your margins. If you just say "it costs me $100 less to develop in ruby, thus I've made an extra $100" you need to take an accounting course. More to the point, if you are building your business with your optimization being focused on decreasing development time, you have already lost sight of the goal. PHP sucks, but there are a ton of profitable companies that use it because it is wicked wicked fast. In my mind, that makes it suck less. :-) -David

davidw 16y ago
> PHP sucks, but there are a ton of profitable companies that use it because it is wicked wicked fast. In my mind, that makes it suck less. :-) I think in this mini benchmark, it's not so much that "PHP" is fast (as a language, it isn't, really), rather that Ruby + its various frameworks are pretty pokey. In any case though, while I remain a Ruby fan, the grandparent sort of misses the point: by being more efficient, you have a wider range of things that can make you money. If you have to have a huge amount of resources to get some pages up, doing ads or some other low-margin activity might not even be feasible like it would with a faster solution.
- fleitz 16y ago
  You're actually on to my point which is to stop doing low margin activities and focus on high margin activities. Low margin activities are where writing a page in C / C++ might be a really good idea. The performance critical parts of your site can always be rewritten in assembler if need be. If your margin on a page request is 5% your business is probably fucked anyway (unless your serving billions of pageviews per month, there are only a few sites that work on this business model). I'd much rather have a business with orders of magnitude fewer requests and a profit margin on the order of 10s of thousands per page request. What do you think 37Signals margin on a page request for basecamp is? My guess is at least 10,000%.

antirez 16y ago

There is nothing in 99% of Ruby slowness culture that is due to optimizing for the programmer IMHO. It is just the missing profiling step or the right design to be fast most of the times. So many things can be improved without killing any abstraction opportunity. On the other side, profitable or not, users don't like to wait that 200 milliseconds more because the code is not written in the right way.