Slashdot Mirror

← Back to Stories (view on slashdot.org)

Scaling Server Performance

Posted by ryuzaki0 on from the caching-for-fun-and-profit dept.

An anonymous reader writes "When Ace's Hardware's article Hitchhiker's Guide to the Mainframe was posted on Slashdot, they got 590,000 hits and over 250,000 page requests during one day. This kind of traffic caused only a 21% average CPU load to their Java-based web server, which is powered by a single 550MHz UltraSparc-II CPU. In their newest article, Scaling Server Performance, Ace's Hardware explains how this was possible."

4 of 341 comments (clear)

  1. only 600, 000 per day? by vanyel · · Score: 4, Informative

    When I was benchmarking web servers in *1994*, servers could handle 100,000/hr, which is only about 30/sec. You may need a T3 to handle the bandwidth, but any server that can't handle it today is misconfigured.

    1. Re:only 600, 000 per day? by vanyel · · Score: 4, Informative

      Yes, but each one of those wizbang annoyances is just another hit to the server. dynamic generation of pages is the real server killer, depending on how much hoop-de-loop you're going through to make them.

  2. That's hardly impressive by shoppa · · Score: 5, Informative
    When one of the sites that I serve, The Computer History Simulation Project, was slashdotted, I was serving 40-50 pages per second (which is nearly ten times the rate attributed to Ace's Hardware) on a 4-year-old webserver (a K6II-500) that cost about $200 to put together. And the server itself was ticking along with only a few percent CPU usage.

    OTOH, my puny little SDSL connection was seriously maxed out.

    Even old hardware can happily serve up hundreds of documents a second, if the pages are static.

  3. different meanings of "dynamic" pages by Confuse+Ed · · Score: 4, Informative

    They've really simply discovered that dynamically generating essentially static content is a bad idea : the 'dynamic' pages they are talking of are just articles which once written stay the same, and so are serving identical pages to each user.

    Using scripting with database look ups to create such pages is obviously not good - much better is to compile your data in to static pages and serve those. I have done this for my own website using XSLT to generate the html pages with consistant links and menu's etc. - but you do have to remember to re-build it after making any changes or adding new content (I use gnu make to handle the dependancies of one page upon another so it doesn't rebuild the entire site everytime.)

    They've taken the alternative approach of still using a database for the requests, but then caching future requests for the same page-id's, which has the advantage of being compatible with their original dynamic generation system, but they don't mention how they handle the dependancy / cascading alterations problem if they change the content (though they could always flush the entire cache of course....).

    Neither of these approaches can help you though if you have real dynamic pages where every request is unique or there are are too many possible pages for caching to be feasible (for example amazon or google).