Live data from Hacker News

On the web server scalability and speed are almost the same thing

antirez.com

21–30 of 67 posts

Re: On the web server scalability and speed are almost the same thing

#21
post #17
post #13

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…

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…

> 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.

Re: On the web server scalability and speed are almost the same thing

#22
post #6

I agree, not only because I've run benchmarks myself but because simpler and faster code is possible. Just a comparison of everything Sinatra does when rendering ( http://goo.gl/6U7yr ) vs what Cuba does ( http://goo.gl/z1Oes ) can shed some light on this issue.

Well, that's that settled! Everyone knows that the execution time of a method is linearly proportional to its length.

Don't you care if _every_ call to render does ~20 unnecessary checks?

Re: On the web server scalability and speed are almost the same thing

#23
post #16
post #13

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…

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... [2] http://googlewebmastercentral.blogspot.com/2010/04/using-sit...

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.

Re: On the web server scalability and speed are almost the same thing

#24
post #11

Earlier quoted context omitted.

This is why Facebook spent so much time and energy working on HipHop. I'm sure they have many caching layers as well, but caching only gets you so far -- eventually you have to look at your code.

interesting how things come and go and come back. Some years ago it was Yahoo moving their web layer from C++ based templating to something of more higher level, now Facebook [implicitly] moves their layer down to C++ ...

This is logically just nonsense. So the php compiles to C++ now? The devs still write in php, they don't move to another language (well they use a somewhat restricted set of php, but a lot of places do that anyway for various reasons).

It is as silly as saying anyone programming in a JVM language is just programming in Java, or anyone using a language which compiles to machine code is just using assembler. (implicitly of course!)

Re: On the web server scalability and speed are almost the same thing

#25

Earlier quoted context omitted.

interesting how things come and go and come back. Some years ago it was Yahoo moving their web layer from C++ based templating to something of more higher level, now Facebook [implicitly] moves their layer down to C++ ...

This is logically just nonsense. So the php compiles to C++ now? The devs still write in php, they don't move to another language (well they use a somewhat restricted set of php, but a lot of places do that anyway for various reasons). It is as silly as saying anyone programming in a JVM language is just programming in Java, or anyone using a language which compiles to machine code is just using assembler. (implicitl…

>anyone using a language which compiles to machine code is just using assembler

obviously it depends on the share of time the one spends tweaking generated code and the compiler's codegen.

Re: On the web server scalability and speed are almost the same thing

#26
post #21
post #17

Earlier quoted context omitted.

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…

> 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'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%.

Re: On the web server scalability and speed are almost the same thing

#27
post #21
post #17

Earlier quoted context omitted.

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…

> 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,…

I shouldn't have thrown in that line about PHP, that was a total tangent. And in any event, I agree with your response. :-)

Re: On the web server scalability and speed are almost the same thing

#28
post #26
post #21

Earlier quoted context omitted.

> 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'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 m…

"You're actually on to my point which is to stop doing low margin activities and focus on high margin activities."

That's something I would certainly endorse. I didn't get that out of your post, I completely agree. Engineers who start companies often overlook this fact and focus on the entirely wrong set of problems when building their business.

Re: On the web server scalability and speed are almost the same thing

#29
post #17
post #13

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…

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…

My point is that out of the gate I'd rather have 2011 tools running on 1999 hardware than 1999 software running on 2011 hardware. A 2011 dev team will run circles around a 1999 dev team because their tools are better and allow them to iterate much more quickly. By the time your startup overwhelms a Pentium 3 server you should have enough profit to by new stuff.

Re: On the web server scalability and speed are almost the same thing

#30
post #17
post #13

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…

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…

Page load speed does relate to profitability, but your language choice most likely won't move the needle so far that you notice a difference. My startup's Rails-based homepage averages ~11ms render time.
Post reply on HN