Believe it or not, but AnandTech, once known as "Anand's Hardware Tech Page" had its roots on a free web hosting company that you may have heard of, Geocities. Back in April 1997, when the site was hosted at Geocities, the traffic was minimal and so were the annoyances of running a Geocities based site. There were no pop-up windows, no forced ads, just 2MB of free webspace and a suggestion to put a Geocities logo on your site.

Back then, you could count the number of hardware enthusiast sites on one hand, in fact, it would only take a couple of fingers. The big companies didn't really take the web seriously back then, although it wasn't very long ago, in Internet-time, it was an eternity. It was during this relatively calm period that AnandTech started to gain some ground and began to develop into what it is today.

The process was a very long one, spanning the course of almost 3.5 years and counting. And during that time, as long time AnandTech readers will vividly remember, we've been constantly hopping from one hosting provider to the next and more recently, we've been caught upgrading our server capacity more than a few times.

The reasons are simple, the more popular AnandTech gets, the more traffic comes our way. And the more traffic we get, the more powerful and plentiful our server solutions have to be in order to make sure that when you click on that link, today's articles, web news, forums and even our site comments pop up as soon as your connection can download them.

Between Geocities and the time we actually got our first physical server, AnandTech was hosted on shared servers, meaning that there were multiple websites hosted on a single box. This was perfectly suitable for us at the time since, although our traffic was increasing, it wasn't great enough to warrant a move to a dedicated server.

The first dedicated server AnandTech ever moved onto was in the middle of 1998, the server itself was a Sun Microsystems' Ultra10S (left). Our pleasant experience with Sun would lead us to make the next server upgrade one that bore the same bright name.

The next upgrade actually marked a fairly big step in AnandTech history, it was our first attempt at a database driven site. Running Oracle as the database back-end, and Allaire's ColdFusion as our web front-end, our next server was a Sun Microsystems Enterprise 250 (right). For those of you that remember the first time we went live with this setup in December of 1998, it was accompanied by our review of the AMD K6-III processor, months before AMD's official announcement. That review not only managed to garner quite a bit of attention, but more importantly, it managed to take down our brand new server.

Our experience with Oracle, ColdFusion & Solaris combined left us with a very bad taste in our mouth. It turns out that the ColdFusion port for Solaris wasn't as mature as the NT port, in fact, CF for Solaris wasn't even a native port to Solaris, which caused quite a bit of trouble, including countless nights spent baby-sitting the server.

While our discovery process was continuing, our developers were combating the excessive load caused by people hitting the K6-III review by rewriting some of the Solaris threading libraries. It turns out that we picked the perfect combination of Operating System and application software, since none of it was working properly together.

We managed to get the site running in a fairly stable fashion on the Enterprise 250 server, that we quickly upgraded to house a second CPU as well as another 512MB of RAM provided by Memman.com. But within a couple of months it quickly became evident that we needed to upgrade to a better solution.

When it comes to serving dynamic content, which is what we do at AnandTech, it is best to have your database (where all of the content is stored) and your web server (what outputs the content to the user) on separate boxes. It doesn't take a rocket scientist to figure out why this is a better solution, but at the same time it took long enough for us to make the move towards a 1 DB + 1 Web server solution.

Learning from our mistakes, we didn't look towards Sun for our next server upgrade, instead we wanted to put ColdFusion on a platform it was known to run well on, Windows NT. Since the upgraded Enterprise 250 box wouldn't have a problem running solely as a database server (Solaris & Oracle got along quite well without CF in the picture), we looked towards putting together an ultra-fast web server.

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

Database Server Number 1

As we continued our learning process, it quickly became evident that our Enterprise 250 server was in desperate need of an upgrade. Not memory, and not CPU wise, rather our database server was suffering from I/O bottleneck problems, the worst type of problem you can have with a database server other than having one that's not operational. With only a single SCSI drive in the DB server, the web server was left in a situation where, under load, the disk performance of the DB box was slowing down the amount of time it would take to serve a page.

After weighing our options, and realizing that it was more cost effective for us to put together a new x86-NT system than keep on upgrading the Sun box, we began constructing a new DB box to alleviate our I/O bottleneck problems.

The new DB box used the same Dual Pentium III Xeon 500's as the web box, each with 1MB of L2 cache running at the core clock speed. Having a large cache is more important to a DB box than having faster clocked CPUs, in most cases that is, and in ours this definitely held true.

We used the same Tyan Thunder X board from the first server, and outfitted it with 1GB of ECC PC100 SDRAM, provided by Azzo.com.

The most important consideration for the DB server was, naturally, its disk I/O performance. While we could have used a single Ultra2 SCSI drive, capable of bursting at up to 80MB/s, we'd still be limiting ourselves in the long run. Instead we picked up an Adaptec AAA-133U2 Ultra2 SCSI RAID card. The AAA-133U2 features three independent Ultra2 channels which would work perfectly with the plans we had for the DB box which was to setup a RAID 5 array with three IBM Ultrastar 9LZX drives.

Add in an extra SCSI drive for the boot device operating off of the motherboard's integrated SCSI controller and our DB box was ready for action.

Since we were migrating away from Sun, we also moved DB software from Oracle to SQL7. There were no problems with Oracle, it was just easier to find developers for SQL7 and the cost of running the latter was noticeably less than Oracle.

Upon doing this upgrade, we also made sure that all of the servers had dual NICs, one for all internal DB traffic and one for all external (net) traffic.

AnandTech gets the Forums...Servers 3 & 4

That two server setup kept us going for quite a while, until, of course, we decided to start hosting the AnandTech Forums on our own servers. The decision to move the Forums to our own servers was made when we realized that it was time to run the site off of more than just a pair of boxes, so if one box were to go down, the entire site wouldn't go down with it.

These two servers were generally configured like the first pair, except we were using 550MHz Pentium III Xeons, and the new DB server featured 2MB of L2 cache per chip. This time around, Azzo.com was the supplier we used for the parts in the systems, and they all worked flawlessly.

The only other change that we made with these systems is that the second Web Server didn't feature an AMI MegaRAID card, rather an Adaptec AAA-131U2, which is a single channel version of the three channel 133U2 card we used in both DB boxes.

Unfortunately it didn't take long for this four server configuration to become saturated. After examining the cluster's weak points, it was quickly realized that the DB servers weren't having a problem keeping up with the traffic. On the highest traffic days, the DB servers were never showing over 20% usage. It was the Web Servers that were feeling the most pain, they were simply running out of CPU time to process the tasks that remained in their individual queues. Knowing the problem, a solution was pretty easy to find...add more Web Servers, but what kind and how many?

Web Servers are interesting devices, mainly because when you're dealing with a cluster of them, bigger doesn't always mean better. What exactly does that mean? Well, for our situation, we could've added two more dual Xeon boxes and gained a bit of a performance boost, or added 4 or 5 single processor Pentium III boxes and seen an even larger performance increase. The main reason for the latter is two fold; First of all, the Pentium III Xeon is still realistically limited to 550MHz since all of the faster CPUs fail to have any real motherboard support without requiring an RDRAM based platform (i840). If each of these servers were to have over 512MB of memory, obtaining that much RDRAM would be quite costly, and not the best option for us at all. Secondly, when migrating from a single processor to dual processors, you don't see a perfect scale in performance (at least under NT/2K). Instead, adding a second CPU often gives you another 20 - 40% performance increase, definitely not the performance increase you'd see if you were to cluster two single processor systems together.

Now, remember what we mentioned earlier, that for Database Servers you want a decent speed CPU but a large L2 cache but for Web Servers you want something with a fast CPU and a fast L2 cache, but not necessarily a large one. With the Pentium III available in speeds up to 1GHz (realistically speaking we could probably get 933MHz parts at a better value) and featuring a full speed L2 cache, there was quite a good chance that a single 1GHz Pentium III server would be able to outperform a dual 550MHz Pentium III Xeon server in our type of Web Server applications. So we had our problem solved, except for one big part of the equation we hadn't considered, what platform would we run these 133MHz FSB Pentium IIIs on?

The i820E chipset is a definite-no, for the reason we mentioned above: RDRAM is still not a cost effective solution for servers. The BX/GX chipsets were a possibility however there is absolutely no way we were going to overclock our servers to run at the 133MHz FSB, meaning we'd be limited to Pentium III 850s but more importantly we'd be limited to the 100MHz FSB and a 100MHz memory bus which could severely hinder performance.

The i815E chipset was the next consideration that came to mind, the only problem here was that the i815E chipset features a 512MB memory limit which isn't acceptable for servers that constantly have a 300MB memory usage under normal load, a number that can most definitely peak above that.

This left us with the VIA Apollo Pro 133A chipset as the only remaining option, however we were talking about a chipset that hadn't really been intended for a high-end application such as web serving. In bringing up the 133A chipset we were struck by an even better idea, what about VIA's KT133 chipset as a platform for web servers...?

Athlons as servers?

A while ago we had the idea of doing a web server benchmark comparison, both for our own information and to include in an upcoming article. This was shortly after the release of AMD's Athlon processor last year, and as you can probably guess, the article never made it to publications. But the benchmarks were actually done and ready to go.

Our Senior Developer, Jason Clark, put together some custom tests that measured the performance of the processors in the scenario they would be put in if they were running in AnandTech Web Servers. It turns out that in these tests, the AMD Athlon 600 (512KB L2 cache running at 300MHz) was approximately 10% faster than the Pentium III 600 (512KB L2 cache running at 300MHz).

The release of the Coppermine with its on-die, full speed 256KB L2 cache would most likely cut down on that lead or even switch the possession of the top performer award, however we never continued the benchmarks with the Coppermine because the article never made it to publication.

We attributed a large amount of the Athlon's success to the fact that it has such a large L1 cache, but as its clock speed increased we were afraid that the slower L2 cache could become a performance hindrance if it were ever to be used in a server environment.

Now that the Athlon has a full speed 256KB L2 cache, in addition to its already large 128KB L1 cache, the processor is actually a perfect candidate for a Web Server; and as we mentioned earlier, you don't necessarily want to have a single dual processor web server, rather two single processor servers, so the current lack of any multiprocessor capable Athlon chipsets wasn't a problem.

The Athlon's effective 200MHz EV6 bus wouldn't be a bottleneck at all, whereas the 100MHz FSB we'd be forced to use on the BX chipset would cause a performance limitation, and the KT133 chipset supports a 133MHz memory bus which was just what we were looking for. Remember, in an ideal setup you want the content you're serving from your web server to come entirely from cache & system memory, so a fast path to the memory is a definite prerequisite.

The only question that remained was, would any of the currently available Socket-A motherboards stand the test of being used as a server platform with all three DIMM slots populated with 256MB modules? While we had done testing to ensure 256MB module compatibility and stability with all DIMM slots populated, we had never done the type of stress testing that would be necessary to simulate the load these boxes would be under as servers.

It was a risk, but we went for it. The first job was picking a motherboard. At the time, neither the ASUS A7V nor the ABIT KT7-RAID were widely available, but another board that left us with a very good impression was Microstar's K7T Pro, and it was readily available to us. After picking a motherboard, we contacted Corsair & Mushkin to have a total of 15 256MB modules built that would work properly in a KT133 based motherboard.

Click to Enlarge

As far as CPUs went, the Athlons with the best price/performance ratio at the time were the Thunderbird 800s as they sold for noticeably less than the 850MHz parts, so if you're interested in setting up a similar system, something around the 800 - 850MHz range would be ideal from a price/performance ratio perspective. Keep in mind that this was before the most recent price drop however.

The servers we ended up putting together made use of 1GHz Thunderbirds from AMD, and as we originally hypothesized, one of these servers should be able to offer performance greater than one of our older dual Pentium III Xeon 500 boxes.

We put together a total of 5 new servers, this was in our most recent trip to Pittsburgh (we are hosted at a datacenter there) that many of you caught wind of from our front page post. Each of the servers was configured identically, and all were to be used as Web Servers, with the exception of the fifth server which would act as a mail/stats/admin box for AnandTech but would also work as a Web Server should the need arise.

Since these servers would be running alongside our current web boxes we saw no need to have even more data redundancy and ditched the idea of setting up RAID 1 arrays on each one of these boxes. In fact, since the disk usage on our previous web boxes was so low, we decided to forgo SCSI all together and simply used some 20GB Ultra ATA/66 drives in these new servers. There is very little disk access required by our web servers and there was really no reason to have 5 more RAID 1 arrays of Ultra2 SCSI drives if we weren't going to use the added performance those drives would offer.

With that said and done, AnandTech is currently running off of a total of 9 servers, two of which are dedicated solely to keeping our wonderful Forums readers running quickly and happily, one being our stats/mail/admin box, and the remaining 6 running AnandTech (1 acting as a Database box). And with this many servers, they were definitely all placed in Rackmount cases, 5U cases for the Xeon servers and 4U cases for most of the rest. Mushkin was the supplier we turned to for our rackmount cases, and they actually offered pretty good rackmounts for a company that specializes primarily in memory. The units have been housing and cooling these 9 servers perfectly thus far, and we haven't had any complaints at all.

Behind AnandTech - The Server Configs

Without further ado, let's get to the actual server configs of the 9 boxes behind AnandTech: