Building a Better Webserver 286
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 (Score:4, Insightful)
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 (Score:5, Insightful)
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... (Score:4, Insightful)
argh, server performance vs BANDWIDTH (Score:4, Insightful)
Why Sun? (Score:3, Insightful)
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 (Score:5, Insightful)
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? (Score:5, Insightful)
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 (Score:3, Insightful)
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 (Score:3, Insightful)
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.