The webserver wasn’t even close to taxing the database server. At low levels of simulated load, the new setup was superior to the current server… however as load scaled, performance suffered dramatically. In fact, even when the applications server had hit incredible loads, the database server was only mildly taxed.
We swapped the roles of the two servers and tried our load testing again: the load scale between the two servers was still skewed: the webserver was simply not powerful enough to tax the database server in a linear relationship, so our scaleability would be hampered by this bottleneck.
Right then we decided to head straight back to the drawing board. The CPU power of our applications server was obviously incapable of scaling the way we wanted. So a whole new plan was called for.
Defining our expansion criteria
We restarted by defining our server requirement expectations over the next year. We wanted to create a setup that could handle no less than triple our current traffic without being loaded to the point that the user experience deteriorated. But we also wanted to handle sudden growth or periods of activity that didn’t fit with our normalized expectations, which predicted we would roughly double our usage within the next 8 months.
To satisfy this demand, we decided to architect a setup that could handle triple our current load, but with the expectation that the setup would be retired and upgraded once the server had hit only 75% of that capacity. The trick was to stay ahead of our growth – so we decided on a 6-8 month server upgrade cycle.
Our decision was quick: we needed more powerful servers, and we needed to distribute the load of the applications demands by segregating tasks between several applications servers.
Plan B – December 2001
The CPU dependency of our applications servers prompted us to opt on multi-processor setups. Two Athlon MP systems would bear the brunt of the applications; one each for the main site and the rapidly growing forums. The database system was to be an Intel Dual PIII 1.13Ghz system, but after more research and consultation with different administrators, we decided the last system would be better served as yet another Athlon MP system.
We ruled out the use of IDE drives early on; from experience, storage I/O bottlenecks are the hardest to overcome once a system is set up and Gigabytes of data already stored. We decided to go with high-end, high-capacity SCSI drives from Seagate and set up a RAID 0 configuration.
The decision to go with RAID 0 was not lightly made – we understood the risk of not having redundancy, but we also understood that speed was extremely important to us, and drive failure would not be a huge set back on the forum applications server or the database server – if we kept timely backups. Also, we were worried about any potential performance hit from a RAID 5 setup, and setting up RAID1+0 was cost prohibitive for our level of use. Because we weren’t running a mission critical server cluster, we decided to sacrifice the little safety that RAID 1 would have offered, and go for storage capacity and speed.
forums
send article 
hardware newsletter 
article comments (18)
Digg this!
del.icio.us