7 ms·

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

• deleted 16y ago
  [deleted]
• deleted 16y ago
  [deleted]
• univerz 16y ago
  and that's why we use cppcms, nginx & mongodb. thousands connections per second with templates, localization, setting timezones, db queries...
  • Luyt 16y ago
    MongoDB is actually a very good suggestion, because http://mongodb-is-web-scale.com/ http://mongodb-is-web-scale.com/
• apu 16y ago
  It would be interesting to see the results of this simple experiment for different web frameworks: almost empty template and no other processing => how many requests per second? If it's much slower than i/o times, something should probably be done about it. (BTW I completely agree with antirez's point.)
  • rimantas 16y ago
    This would be much better experiment. Who does web apps on bare languages anymore? And any decent framework will have some caching implemented, so you don't render the same template if nothing changes.
• soveran 16y ago
  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 http://goo.gl/6U7yr) vs what Cuba does (http://goo.gl/z1Oes http://goo.gl/z1Oes) can shed some light on this issue.
  • tomstuart 16y ago
    Well, that's that settled! Everyone knows that the execution time of a method is linearly proportional to its length.
    • soveran 16y ago
      Don't you care if _every_ call to render does ~20 unnecessary checks?
• megaman821 16y ago
  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.
  • jshen 16y ago
    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.
    • spudlyo 16y ago
      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.
      • megaman821 16y ago
        Facebook is absolute caching nightmare also. However a news site is much easier to deal with.
      • VladRussian 16y ago
        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++ ...
        • sophacles 16y ago
          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!)
• swah 16y ago
  Come on, its more about the moral of the story than if he really used das scientific method to benchmark Ruby and PHP.
  • chc 16y ago
    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?
    • VladRussian 16y ago
      did you really tried it? was the C++ program slower?
      • chc 16y ago
        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.
• 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.
• sdizdar 16y ago
  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).
• d2 16y ago
  Antirez 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.
  • bmelton 16y ago
    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.
  • chc 16y ago
    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.
  • btilly 16y ago
• antirez 16y ago
  I added the code in the blog post after receiving many requests.
• mnutt 16y ago
  It'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 Sinatra is doing some kind of template reloading in dev mode which may explain the speed difference? 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.
  • antirez 16y ago
    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.
    • mnutt 16y ago
      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-overhaul/ http://www.igvita.com/2010/06/07/rails-performance-needs-an-...
      • antirez 16y ago
        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.
• ambiguity 16y ago
  "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.
• antirez 16y ago
  I'm happy that I received so much feedbacks, thank you all! However I see a few comments that missed a bit the point, and this is probably my fault because I did not specified some very important thing: Once you substitute not just an hello world template, but a few templates N times (since you have N comments in the page), the performance starts to be so slow you can't serve more than about 10 requests per second, just because template substitution is so damn slow if you don't preload templates, and the obvious way to do it is calling :erb (you see this in all the Sinatra code around, in the examples, and so forth). 10 requests per second instead of the 1000 you get even with 'N' includes if you perform a faster substitution, or if you preload the templates, or using any other trick, is a huge difference.
  • bad_user 16y ago
    I don't get your article. You're yak shaving, bothering with meaningless issues. In case you want raw rendering speed, you don't choose PHP or Ruby or any other high-level language. You go for straight C/C++ instead -- that's what companies like Google do; that's what Adobe did for Photoshop.com, that's what Yahoo does too for various web services they provide. We pick PHP, Ruby, Python or whatever because there's a point of diminishing returns. For our apps 10 extra requests per second do NOT matter. But 1000 reqs per second do matter, but for a real world app, not for a dumb hello world that doesn't do anything -- and even that may be insufficient, as depending on your use-case you may need 100000 requests per second out of a single server. AND performance on the web == page rendering time, not requests per second. It gets pretty damn hard to have 300ms page loads, and IMHO this is where template rendering could make a difference, but again, not that much.
    • antirez 16y ago
      nonsensical post by definition, sorry. "you don't choose PHP or Ruby or any other high-level language". Why? There is no technological limit, the template substitution should be fast, with minor coding effort it can be fast. It's just lame code. We are not speaking of algorithmic code. Probably language speed is not involved at all, it is just as lame as the framework reloading the template at every page view. And even more lame than that given that even my test loading the template every time was faster.
• asharp 16y ago
  Well, no. Think about it this way: Speed is the number of requests/second a single server can process. Scalability is the amount of computing power you lose when splitting a job amongst multiple machines. Intuitively you can think of it like asymptotic complexity. You can have a really fast implementation of quick sort, but at a large enough input size it will be flattened by a very slow version of radix sort. Similarly you can have the fastest web server on the planet, but if you scale poorly, at some number of nodes even the slowest albiet well scaling system will out perform you.
• ot 16y ago
  Funny. In my freshman year (7 years ago) I was an efficiency and premature optimization zealot, despising anything that wasn't written in C/C++. Then I met a hacker that told me how awesome dynamic language were (in particular Python and Lisp). I told him "but they are some 10-20 times slower than C!". And he replied "Yes, but it takes 10 times less time to code. If the outcome is not fast enough, you can spend the rest of the time optimizing". Since then, Python has been my language of choice, relegating C++ to the optimization of the (few) bottlenecks. Why is this funny? Because that hacker was antirez :)