When you become profitable, it easy to optimize/fix CPU usage and speed (or at least it is not disruptive for your entire product) - it very hard to fix scalability part (including optimizing for memory usage).
On the web server scalability and speed are almost the same thing
31–40 of 67 posts
Re: On the web server scalability and speed are almost the same thing
#32Earlier 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…
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.
Good luck getting a PIII to serve Ruby on Rails content fast enough to keep people interested and cheap enough to still make a profit from advertising.
Re: On the web server scalability and speed are almost the same thing
#33Earlier 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.
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.
Hopefully Varnish will support ESI and gzip compression soon.
Re: On the web server scalability and speed are almost the same thing
#34Antirez why did you title the HN post as "almost the same thing". They ARE the same thing. You are 200% correct. Lets turn it around: Is there an example where speed and scalability are different? Maybe the level of concurrency which behaves differently because performance can drop suddenly when you max out, but really that's just another type of speed. Even in an async environment like node.js you may handle a lot of connections but if there's no speed they hang around for too long waiting for something to return so we're back to speed === scalability in all environments.
Re: On the web server scalability and speed are almost the same thing
#35Earlier 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++ ...
HipHop engineer, here. Unless you consider programming in C++ to be [implicitly] programming in machine language, this doesn't make a lot of sense. Our application engineers write real, no-fooling PHP, at exactly the same level of abstraction as they always have. They usually don't bother compiling it either, instead iterating using our interpreter which behaves more like a drop-in replacement for Apache+Zend.
Re: On the web server scalability and speed are almost the same thing
#36Earlier quoted context omitted.
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.
Good luck getting a PIII to serve Ruby on Rails content fast enough to keep people interested and cheap enough to still make a profit from advertising.
I actually tried this recently. Page load speed isn't too bad at all, but the time it takes to start up the rails stack is awful. It's unusable for dev work.
Re: On the web server scalability and speed are almost the same thing
#37Neither 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…
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.
Re: On the web server scalability and speed are almost the same thing
#38Antirez why did you title the HN post as "almost the same thing". They ARE the same thing. You are 200% correct. Lets turn it around: Is there an example where speed and scalability are different? Maybe the level of concurrency which behaves differently because performance can drop suddenly when you max out, but really that's just another type of speed. Even in an async environment like node.js you may handle a lot o…
I disagree.
Speed at scale and scalability are the same thing, but speed and scalability most certainly aren't. A server that performs really well on a single request, but slows down as requests are added would be considered 'fast', but not 'fast at scale'.
Yes, there are plenty of instances in which this is the case, and most notably, this is a very common affliction with databases. Also, even in scenarios where you can add more web servers to an application stack, you can't necessarily add more database instances, so you scale those UP instead of OUT.
In summary, the statements made in the article are true, but yours aren't really. In the case of web servers, yeah, they're almost the same thing. In the case of other things, they're generally not.
Re: On the web server scalability and speed are almost the same thing
#39Earlier 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++ ...
HipHop engineer, here. Unless you consider programming in C++ to be [implicitly] programming in machine language, this doesn't make a lot of sense. Our application engineers write real, no-fooling PHP, at exactly the same level of abstraction as they always have. They usually don't bother compiling it either, instead iterating using our interpreter which behaves more like a drop-in replacement for Apache+Zend.
I've been looking at HipHop lately -- can you give me a general idea of how much you have to work around HipHop for it to still compile? I know that the references I've seen to it have all indicated that it might choke on certain types of code, but I'm curious as to how mindful you have to be?
Re: On the web server scalability and speed are almost the same thing
#40Antirez why did you title the HN post as "almost the same thing". They ARE the same thing. You are 200% correct. Lets turn it around: Is there an example where speed and scalability are different? Maybe the level of concurrency which behaves differently because performance can drop suddenly when you max out, but really that's just another type of speed. Even in an async environment like node.js you may handle a lot o…
I can give you an example where speed and scalability are different.
Step 1: Create two WordPress blogs served by two Apache servers — one with KeepAlive on and one with it off
Step 2: Benchmark the speeds — you'll see that the KeepAlive one is faster
Step 3: Get a link to each blog on Daring Fireball
Step 4: Notice which server is still accessible (hint: not the faster one)
The server with KeepAlive will fulfill requests faster up to a certain number of people within a certain time span, but past that number it will simply start turning people away while the other server keeps delivering pages a little bit more slowly because Apache's KeepAlive trades capacity for speed.
At any rate, in a real production environment, there are measures you can take to make sure your site is both scalable and fast. Toy examples of poor configurations aren't very informative IMO.