Behind AnandTech - The Search for the Perfect Servers

Web Server Number 1

At the time, the fastest server platform available was the Pentium III Xeon available at speeds up to 450MHz. It turns out that Intel was very interested in seeing how their Xeon would stack up against our UltraSparc IIs, so they managed to get us a pair of Pentium III Xeons running at 500MHz with 1MB of L2 cache each.

Finding a solid motherboard to run those CPUs on wasn't a problem. Tyan's Thunder X was one of the best, if not the best dual Slot-2 motherboard solution, and since it was based on the i440GX chipset, it featured memory support of up to 2GB of PC100 SDRAM.

For a web server, at least in our situation, there wasn't a high demand for disk performance rather the system needed a lot of memory and some fast CPUs. We had already taken care of the CPUs, and adding 1GB of ECC PC100 SDRAM was simple enough which was graciously provided by our friends at Memman.com.

All that was left to complete this server equation was storage, we had been eyeing IBM's Ultrastar 9LZX drives for quite a while, mainly because of their very impressive specs. With a 4MB buffer, these 10,020 RPM drives would definitely eliminate any sort of disk I/O bottlenecks that would be present with our web server.

Ideally, with any web server, you should be caching all the data you're serving (at least the most frequently served data) meaning the amount of disk accesses should be minimized, but since we were interested in setting up a RAID 1 array for our web server (just in case we happened to lose a drive, we didn't want the entire site to go down), we decided that it would make the most sense to go with the best of the best in terms of drives.

Before Insight's acquisition of the company, TC Computers had been our largest advertiser, and gladly supplied us with the two drives as well as an AMI MegaRAID controller to handle the RAID 1 operation.

On the networking side of things, the biggest mistake we made with our first web server was that it did not have a private connection to our DB server (the Enterprise 250), instead the same NIC that was used for public traffic, was also used for what should've been private traffic between the DB and the web boxes. Remember, that every time a page request is received by the web server, it must go to the DB server to actually pull the data, and then send out the completed template all through the same NIC.

The second mistake we made this time around was that instead of using a Rackmount case to enclose the server, we used a Supermicro SC750-A tower, which although was perfect for cooling, it ended up leaving our hosts a little more than displeased because of the sheer size of the case. Live and learn...