I added the code in the blog post after receiving many requests.
On the web server scalability and speed are almost the same thing
41–50 of 67 posts
Re: On the web server scalability and speed are almost the same thing
#42Antirez 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…
Lets turn it around: Is there an example where speed and scalability are different?
Well, actually there are a lot of such examples. For instance consider the idea of caching data in shared memory. This is very fast. But the second you've done it with something that has to remain consistent across requests, you can't have 2 webservers any more. You're fast, but can't scale. (Don't laugh, I know of a number of websites that made this mistake at some point in their history. http://www.kuro5hin.org/ and http://slashdot.org/ are two good examples.)
Concurrency and locking issues provide lots more examples. Having fewer locks over large things is much faster than having lots of little locks. But you get less concurrency. For a toy website, MySQL with MyISAM is fine - lock whole tables. Row level locking as done in Oracle, PostgreSQL or MySQL with INNODB is much slower, but it scales.
I know that you think that this is "just another type of speed", but it really isn't. If a critical lock somewhere deep in a database is operating at 95% of maximum capacity, there is basically no visible effect on performance from the lock contention. At 101% of capacity, your database falls over. The characteristic failure mode isn't that you get slower as the request rate increases. It is that you max out your capacity and then crash if you try to go faster. I've been there, and it isn't fun.
Now with all of this said, there is a large, obvious, connection between speed and scalability. Suppose that you are comparing 2 languages, one of which runs twice as fast as the other. You can scale the slow one - just run twice as many boxes. But now you need twice as many database connections. Holding those connections open consumes resources, so you need a bigger database. And so on.
Therefore the faster environment can frequently push off the point at which you start encountering other scalability issues. But speed and scalability are not at all the same thing.
Re: On the web server scalability and speed are almost the same thing
#43It's unfortunate that he included benchmark numbers because people will discuss the numbers rather than his main point. Since we're discussing the numbers anyway, antirez, were you running Sinatra in production mode? My benchmarks on my MBP look like this:
"hello", development mode 1620 req/s
erb :index, development mode 1000 req/s
"hello", production mode 1620 req/s
erb :index, production mode 1350 req/s
That said, I think antirez is right that there are lots of opportunities for making ruby faster. I'm particularly hopeful about JRuby's use of invokedynamic and all of the work that is going into Rubinius.
The thing is, once you're able to scale out horizontally then you're back to riding the Moore's Law cost curve. If my ruby app requires 4 machines now, it'll require 2 machines in two years. Should I pay the up-front cost now of writing it in something lower-level? It depends, but in lots of cases probably not.
Re: On the web server scalability and speed are almost the same thing
#44It's unfortunate that he included benchmark numbers because people will discuss the numbers rather than his main point. Since we're discussing the numbers anyway, antirez, were you running Sinatra in production mode? My benchmarks on my MBP look like this: "hello", development mode 1620 req/s erb :index, development mode 1000 req/s "hello", production mode 1620 req/s erb :index, production mode 1350 req/s I assume Si…
Hello Mnutt, I'm running the test into an MBA 11", it's very very slow, this is why this numbers are so different. The MBA is a good development machine as everything seems slow even if it is just a bit slow :)
Btw the PHP code is reloading the template at every request for sure. I pasted the example code I used on the blog.
Re: On the web server scalability and speed are almost the same thing
#45It's unfortunate that he included benchmark numbers because people will discuss the numbers rather than his main point. Since we're discussing the numbers anyway, antirez, were you running Sinatra in production mode? My benchmarks on my MBP look like this: "hello", development mode 1620 req/s erb :index, development mode 1000 req/s "hello", production mode 1620 req/s erb :index, production mode 1350 req/s I assume Si…
Hello Mnutt, I'm running the test into an MBA 11", it's very very slow, this is why this numbers are so different. The MBA is a good development machine as everything seems slow even if it is just a bit slow :) Btw the PHP code is reloading the template at every request for sure. I pasted the example code I used on the blog.
Sorry, I just posted numbers to show the difference between dev mode and production mode.
I guess what I don't understand is: if you're running a site in development, isn't 250 req/s enough? And if you're running in production, do you need to reload the template on each request?
Unless you're just using this as an example indicative of the fact that ruby/rails could surely stand to be faster, in which case I completely agree. As does Ilya Grigorik: http://www.igvita.com/2010/06/07/rails-performance-needs-an-...
Re: On the web server scalability and speed are almost the same thing
#46Earlier quoted context omitted.
Hello Mnutt, I'm running the test into an MBA 11", it's very very slow, this is why this numbers are so different. The MBA is a good development machine as everything seems slow even if it is just a bit slow :) Btw the PHP code is reloading the template at every request for sure. I pasted the example code I used on the blog.
Sorry, I just posted numbers to show the difference between dev mode and production mode. I guess what I don't understand is: if you're running a site in development, isn't 250 req/s enough? And if you're running in production, do you need to reload the template on each request? Unless you're just using this as an example indicative of the fact that ruby/rails could surely stand to be faster, in which case I complete…
Ok my fault that did not said this in the blog post.
I was playing with Sinatra, and my real page involved substituting a few nested templates, with different parts of the site. News box, comments boxes, ...
The result was... 30 requests per second once a few templates started to stack, and with mostly toy code. It is easy how things can get worse just doing a few mistakes along this path.
Re: On the web server scalability and speed are almost the same thing
#47Neither 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…
On your point #3. Actually, you are incorrect. Profit is revenue - all costs. Whether or not it counts as COGS is only relevant for gross margin, a metric which isn't the best to judge software companies. R&D is an expense, so it affects your profitability and your net margin. If your company spends $100 less, that's $100 more you have in the bank, $100 less that you need to sell people on.
http://www.investopedia.com/terms/g/grossmargin.asp http://www.investopedia.com/terms/n/net_margin.asp
Re: On the web server scalability and speed are almost the same thing
#48Neither 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…
What's stopping you from profiling your rails app after you finished it before the home built php solution? You always want to decrease development time, product out the door is what matters as Windows and Linux/Unix prove that even with superior alternatives (plan9, inferno) being first and with momentum is infinitely more valuable.
Re: On the web server scalability and speed are almost the same thing
#49Earlier quoted context omitted.
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?
If you stick to the brightly lit parts of the language, things will work. The Facebook codebase was and is enormous, so the vast majority of PHP has to work as advertised. The one big thing that's ruled out is eval, but other wacky PHP tricks ($f(), $C::staticMethod, $obj->$methodName(), foreach order, etc.) work. Outside of eval, you have to go out of your way to break it.
That said, it's a young project, and things can be a bit rocky. Including compilation in your deployment process is also a pain; do not kid yourself about that. It's kind of "industrial strength" in general; unless you care about how many PHP requests you can squeeze out of a unit of hardware, HipHop doesn't have much to offer.
Re: On the web server scalability and speed are almost the same thing
#50"Your only bottleneck in a web app should be: the databases, the workers. There are no excuses for the page generation to be slow. In the web speed is scalability because every web server is conceptually a parallel computation unit. So if the web page generation takes 10 ms instead of 100 ms I can server everything with just 10% of the hardware."
If the database is the bottleneck then the speed of web page matters much less. A page with a single 50 ms query will take %40 of the hardware (60 ms versus 150 ms).
This is even much less of an issue if you take into account how long it took for his test. PHP served 1500 requests per second vs Ruby's 250 requests per second which is equal to 0.7 ms per page and 4 ms per page. Assuming again you have a single 50 ms database query you are looking at 50.7 ms vs 54 ms which means you will need ~94% as much hardware. This is assuming that the database and webserver are on the same machine.
If one puts them on separate machines then the time of execution does not matter as long as the time it takes to query the database is less than the time it takes to render the page. Now this is bad in terms of page load as 50 ms + 49ms for page rendering is much more than 50 ms + 0.1 ms but in both cases you will be able to serve the same number of requests per second. This of course assumes that this is running in a multi threaded environment which allows one thread to sleep and other threads to start while waiting for a response from the database.