Live data from Hacker News

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

antirez.com

11–20 of 67 posts

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

#11
post #10

Slow template rendering only matters if your pages are heavily personalized for each user. Stick Varnish in front the page and serve over 2,500 request/sec and use whatever framework you are most comfortable with.

all things can not be cached heavily. And even for things that can you still need to regenerate the cached data to some degree. Code that is ten times slower will require 10 times more hardware even if you cache. The cache only makes the number you're multiplying by 10 smaller.

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.

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

#12
post #9

Come on, its more about the moral of the story than if he really used das scientific method to benchmark Ruby and PHP.

All I see is a guy who set up a naive test app in Sinatra (served by WEBrick for all we know) and found that it served fewer requests per second than a test app he wrote in PHP. Then, where most people would have tried to find the slowdown, he just skipped all that and decided that "apparently" Ruby is slow and "probably there is some lame reason why this happens." On the basis of one application with one particular set of libraries that he didn't even benchmark.

Like, if I run a C++ program off a 2X CD-RW drive in a computer with a Motorola 68000 and it's slower than my Ruby site is on my 8-core Mac Pro with an SSD, do I get to write a rant about how slow C++ is?

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

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

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

#14
post #11
post #10

Earlier quoted context omitted.

all things can not be cached heavily. And even for things that can you still need to regenerate the cached data to some degree. Code that is ten times slower will require 10 times more hardware even if you cache. The cache only makes the number you're multiplying by 10 smaller.

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.

Facebook is absolute caching nightmare also. However a news site is much easier to deal with.

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

#15
post #11
post #10

Earlier quoted context omitted.

all things can not be cached heavily. And even for things that can you still need to regenerate the cached data to some degree. Code that is ten times slower will require 10 times more hardware even if you cache. The cache only makes the number you're multiplying by 10 smaller.

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

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

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

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

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

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

#18
post #10

Slow template rendering only matters if your pages are heavily personalized for each user. Stick Varnish in front the page and serve over 2,500 request/sec and use whatever framework you are most comfortable with.

all things can not be cached heavily. And even for things that can you still need to regenerate the cached data to some degree. Code that is ten times slower will require 10 times more hardware even if you cache. The cache only makes the number you're multiplying by 10 smaller.

It seems a lot of people over look ESI support in Varnish. Proper use of ESI in pages that have content sections that update at different intervals can make a large impact.

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

#19
post #12
post #9

Come on, its more about the moral of the story than if he really used das scientific method to benchmark Ruby and PHP.

All I see is a guy who set up a naive test app in Sinatra (served by WEBrick for all we know) and found that it served fewer requests per second than a test app he wrote in PHP. Then, where most people would have tried to find the slowdown, he just skipped all that and decided that "apparently" Ruby is slow and "probably there is some lame reason why this happens." On the basis of one application with one particular…

did you really tried it? was the C++ program slower?

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

#20
post #12

Earlier quoted context omitted.

All I see is a guy who set up a naive test app in Sinatra (served by WEBrick for all we know) and found that it served fewer requests per second than a test app he wrote in PHP. Then, where most people would have tried to find the slowdown, he just skipped all that and decided that "apparently" Ruby is slow and "probably there is some lame reason why this happens." On the basis of one application with one particular…

did you really tried it? was the C++ program slower?

I can guarantee it. I was thinking of an actual computer I had, and the read speed of the drive alone was slower than the time it takes Mongrel to serve up a page with Rails.
Post reply on HN