Building a Better Webserver

msolnik writes: "The guys over at Aces' Hardware have put up a new article going over the basics, and not-so-basics, of building a new server. This is a very informative, I think everyone should devote 5 minutes and a can of Dr Pepper to this article."

What all companies should do

[Delrin]

But don't.
Actually a very interesting article, to be honest, in my 1 year of building webserver applications. I haven't gone through a process like this once. Usually we make a rough guess about how the application has performed (or more usually underperformed on existing servers, and just scale a percentile. As you can imagine, this is hardly realistic. Thanks for the read!

Re:Quick page, good read

[DavidJA]

but I figure it's best to spend the money early on, get a good setup going that can handle high volumes

Throwing money at the problem is exactly the WRONG approch. You need to start by spending time PLANNING and RESEARCHING the best way to do things.

For example, if you are setting up a dynamic site like ./, which is serving 100 pages/second. It obviously needs to be dynamic, so you need a database to store all the comments in.

There are two ways to do this, one is to serve content straight out of the database, but this means that for every page you serve up, there needs to be a database query. (the database queries are the expensive part in terms of time it takes to serve a page). The other way would be to serve the articals as static pages which are generated every minute or so by a process on the database and pushed down to the web server, which serves these up as static pages.

The advantage of this is that insted of 100 database queries per minute, you end up with, maybe 10 queries per minute to populate the static pages. Sure, you site is no longer 100% dynamic, but it is a whole lot faster, and you have saved thousands of dollars to boot!

This is just one small off-the-top-of-my-head example of where PLANNING sould become way before spending any money.

the Ultimate Webserver is...

[GCP]

...the one with a lot of mirrors.

argh, server performance vs BANDWIDTH

[green pizza]

Is it just me, or do most folks confuse these two. If a popular website only has a 9 Mbps pipe to the Internet, it doesn't matter how many Crays they have running their webserver farm, they're only going to be able to churn out 9 Mbps (minus overhead). Granted that the converse is possible... gobs of bandwidth, but a slow server... but I would imagine that bandwidth is the limiting factor of at least 99% of websites.

Why Sun?

[hughk]

Having a quick dig through the article at the far from lightning speed that a /.ed site runs at, I am still no absolutely clear why they stuck with SPARC architecture.

SPARCs come from Sun, everybody makes a PC - so guess which is cheaper? We see some reasons why they went for the Blade (a nice machine, but rather more expensive than a couple of PCs).

Please get this right, I'm no x86 fan, but I love the competition going through the line from the processors, chip-sets, mother-boards, etc. This has got to ensure that unless you really want the 2GHz Pentium 4, you have plenty of choice.

As for reliability, I don't know the Blade, but the SPARC 20s used to give some headaches over their internal construction. It always seemed a little complicated with the daughter boards and they seemed to lose contact after machines were moved around.

Re:Quick page, good read

[NerveGas]

<but I figure it's best to spend the money early on, get a good setup going that can handle high volumes>

Actually, that's a terribly wasteful way to go. If you work on an easily-scalable infrastructure, then you can pretty much purchase capacity as it's needed, which not only frees up capital for a longer time, you end up spending a lot less, as the price of computers is always dropping, and the performance is always going up.

steve

Re:Why Sun?

[nuetrino]

Because you have absolutely no clue as why they chose the Blade, one must assume you did not do much digging before wasting bandwidth with your post. The article went into great depth explaining why they bought the Blade. The high points were power consumption, lack of a serious and fully supported OS, lack of a server class PC in their price range, the $1000 price tag, and the fact they already had the software written to run on Solaris. They admitted that could get an x86 for a little less, but it wasn?t enough to make good business sense.

I am amazed at how people buy into the myth of cheap PC?s. Yes, if you are technically oriented and are not running critical applications, a cheap PC will be ok. On the other hand, I have been involved with several enterprises in which my employer insisted on going with cheap PC?s at the expense of short- and long-term productivity. One certainly cannot get a server class PC for $500, and there is few if any available for $1000. I would not say that a Blade would make a good office machine, but it seems to be a good choice for a server.

Re:argh, server performance vs BANDWIDTH

[shut_up_man]

The server being the bottleneck does sometimes happen, particularly with high-volume websites. If hits are coming in faster than the server can process them, they queue up. CPU usage skyrockets, free memory shrinks, the server starts to thrash, and it often spirals down into a state where it refuses new connections until it's processed the ones it has. This is why you often see HTTP 1.1 / Server Too Busy errors - the server has been swamped. Not the link.

Tuning a web server is also a bit of an art - most default settings don't take full advantage of the hardware, they throw out Too Busy messages before the CPU/memory is full utilised. Parameters such as queues and worker threads need to be increased to accept more connections. Of course, this can lead to overtuning, where the parameters are set too ambitiously, the server bites off more than it can chew, and chokes.

Modern web servers on modern hardware can serve a frightening number of flat html pages per second - the real problems stem from poorly optimised dynamic code, usually to do with databases. Sure it's cute to have the site navigation automatically generate from a database query, but it's insanely inefficient. It'll work great under normal light loads, but when you get linked from Slashdot, you're dead.

Disk IO on the Blade 100

[Doktor Memory]

...is crap crap crap crap crap. The Blade 100 is one of Sun's IDE-based machines. Because Sun expects that such boxes are going to be used either as low-end workstations (the Blade 100) or disk-avoiding compute farm servers (the Netra X1), the disk subsystem of them is painfully below par: Sun routinely ships under-speced IDE disks (remember the 4800 RPM drive? Sun does, and they've got a whole warehouseful to refresh your memory with!) and compounds the problem with Solaris 8's ATA/IDE drivers, which are the worst in the known universe -- watch your entire system drag to a half as the OS attempt to write out a .5MB file! Whee!

I don't know what Ace's traffic numbers are normally like, but using a Blade 100 for anything other than a small, personal website is flat-out folly. At a minimum, they should have been using a Netra T1/AC200 ($3k, nicely configured, and a 1U rackmount machine to boot), and I would probably have thought seriously about scrounging a used E250 or E220R off of Ebay.