Scaling Server Performance

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

Comments

How they did it...

[darkov]

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 ... they didn't respond to any of them.

So the article on preventing the /. effect ...

[burgburgburg]

will be tested to see if it's meaningful. I like that. That is definitely putting your money where your mouth is.

Of course, it is incumbent upon all of us to rush out and try to the link to the article. And some of us to actually read it as opposed to just reading the title.

<blows horn>

[Anonymous Coward]

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.

Battlestations!

SLASHDOT THEM AGAIN!!!

only 600, 000 per day?

[vanyel]

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.

Re:only 600, 000 per day?

[stratjakt]

In 1994 websites were nothing more than text documents with perhaps a handful of small .gifs in them. They werent plastered with media-intensive-ads, java applets and shockwave whizbangers, background music, video clips streaming off the same server and blah blah blah innovation.

The web-design and server world seems to be focused on quantity, not quality.

And frankly, much of what /. links to are personal sites run off of a DSL line. I think the effect has more to do with bandwidth than server load.

Re:only 600, 000 per day?

[vanyel]

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.

yes.

[krog]

seeing as it took Slashdot 35 seconds to serve me up this comments.pl?op-Reply page, yes, i think we are supposed to be impressed.

But the ad server is slashdotted

[ites]

Which is very funny: this is an article explaining how a web site survived the /. effect, thus trying to catch the /. readers back for a second round, and getting lots of advertising hits at the same time. If only that server could keep up.
Now, a while back on /. I saw a report about a 200Mhz (?) PC running Windows 95 and with about 30 hard disks, that also seemed to do very well under the /. effect.

Ones that crashs

[MCMLXXVI]

I would be more interested in stats on a webserver that took a puke. It would be interesting to see what started the dominos falling and what ultimatly brought it down. It would be as good a learning experiance as this article is.

That's hardly impressive

[shoppa]

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.

Re:That's hardly impressive

[shoppa]

I agree, dynamic content is very much more challenging - but is it wise for Ace's (or any of the other sites) who are serving up static stories to do so through dynamic methods?

I am familiar with serving dynamic content of very high information density, and let me tell you, Ace's doesn't compare. The data I serve from work is updated every second; the stories on Ace's (and most other hardware-review sites) change every couple of days.

Getting it right the first time?

[ites]

>Wagner LLC Consulting Co. - Getting it right the first time
>Garth Brooks covers this in his famous book "The Mythical Man Month" where he proves in a controled lab environment that Java under X86 runs on the order of Olog(n) slower than it does on a RISC chip like an UltraSparc.

WTF? Fred Brooks wrote this book, and I don't seem to remember RISC or UltraSparc chips, not to mention Java, in 1974. Garth Brooks is (AFAIK) a country music singer. Try again.

Isnt the real problem BANDwidth?

[Kevin Stevens]

I never really thought that the problem lied with the server's hardware, but in the bandwidth to the host. Shouldn't an article be written about how to conserve bandwidth during a slashdot effect? Even older servers should be able to handle 100 requests per second. I think most FPS's are alot more taxing than that.

looks like they spoke too soon...

[pjrc]

To point out the obvious, it looks like they're slashdotted.

Reloading their page a couple times (2nd page of the article, not the one slashdot linked to), I'm getting occasional 503 errors, and the rest are taking a very long time to load. Usually the page comes up with some "broken" images that didn't load.

At the bottom of each page, there's a number that seems to indicate the time they believe their server spent serving the page. Usually is says something like "2 ms" or "3 ms"... That may be how long their code spent creating the html, but the real world performance I see (via a 1.5 Mbit/sec DSL line) is many seconds for the html and many more for the images, some of which never show up, and sometimes a 503 error instead of anything useful at all.

So, Brian, if you're reading this comment (which will probably be worthy of "redundant" moderation by the time I hit the Submit button)... it ain't workin' as well as you think. Maybe the next article will be an explaination of what went wrong this time, and you can try again???

different meanings of "dynamic" pages

[Confuse Ed]

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

big difference between 1am and 2pm!

[ledbetter]

I remember reading that original article, and yes, I was impressed at the responsiveness of the server. But before they are congratulated so much, consider this. The original story was posted on slashdot at 1AM.. so the initial spike of activity resulting from the linking being in the top few on Slashdot was directly proportional to the number of people on Slashdot at the time. As you can see from their graphs (if they're showing up for you) that traffic spiked, then continued on during the day.

This time around, the link got posted at 2PM not 1AM, and so far as I can see, they handle this flurry of hits much less gracefully than the previous ones! There are a lot more people online at 2PM than 1AM (all arguments of nocturnal nighthawks and people in other time zones aside).

Who cares how long it takes for static pages?

[pcraven]

Some static story pages? Who cares?

It all depends if you are actually doing something of interest.

Like the comments in Slashcode, most apps go from static, to dynamic, to static caching of dynamic pages.

At DTN we served up customized portal pages to people with commodity and equity quotes, news, graphs, etc. Since they didn't have any money we had to use a load balanced Pentium Pro and a Pentium II. The app had no problem serving the load, and it was fast.

Now that I work for companies that have money, our apps run really slow. Developers get expensive machines and don't know how to optimize any more.