Web Structure and Infrastructure

Like many Web masters, I'm not a systems or network specialist. I have no formal training or extensive experience in either area. I'm strictly responsible for managing the development and production of Windows NT Magazine's Web sites. Because of the Web technology group's ever-growing needs, short development timelines, and a need to address problems quickly, my group has become responsible for its own tech support. This added responsibility can be taxing at times and takes away from what we are supposed to be doing. However, tech support also keeps us current on system configuration issues. The best part about providing our tech support is that we can limit access to the Web servers. Because our IS department doesn't support our machines, IS can't access them. The whole situation is a Catch 22--we can limit access to the machines, which makes security easier, but we also have to support them. I imagine the Web technology group will soon have a support mechanism instead of the development team having to support itself.

In terms of tech support, the biggest trouble area has been selecting the proper hardware and software for hosting our Web site. We've switched Web server software and hardware several times during the past two years. Some of these changes resulted in dramatic improvements; others had the same effect as opening a can of worms.

The Right Hardware and Software
Did you know you can have too much horsepower in your hardware? When I upgraded our single Pentium Pro 200 Web server to a quad Pentium Pro 200 machine, the Windows NT Magazine Lab, which does all sorts of performance and scalability testing, tried to warn me that I might be disappointed. We were going to launch the Windows NT Solutions Directory, and I wanted to start gearing up for it.

Initially, we set up the quad Pentium Pro machine to run Internet Information Server (IIS) and SQL Server--we were quickly disappointed. Some testing showed that this configuration worked well, but when we put it under heavy load, it choked. Too many processes were competing for the same resources. So we went back to running the Web site from the single Pentium Pro 200 machine and moved the SQL Server to a separate dual Pentium 100 machine. This configuration didn't run circles around the quad Pentium Pro 200 machine in performance, but it was stable.

After a lot of testing, tweaking, and shuffling, we ended up with a quad Pentium Pro 200 with 256MB of RAM for the Web server and a quad Pentium Pro 200 with 512MB of RAM for the SQL Server. Of the two, the database server running SQL Server 6.5 has been magical. No matter what type of Web testing we do against other Web servers, this machine screams. It concentrates on one thing, providing database access, and it performs this task very, very well. For the SQL Server, I wouldn't want any other system.

Besides using the right system, configuring it with lots of RAM helps. Added RAM is nice for performance when you can get your applications to use it. However, 512MB is painful when you have to reboot your live machine and wait through the memory test. Unfortunately, our servers do not let us escape the test, so we have to wait for the machine to verify all the memory.

The Web server has been a different story. Our Web server hosts several applications, unlike the SQL Server, which provides only one service. Our Web server hosts IIS 3.0, Cold Fusion 3.0, AdJuggler, and IIS Assistant (IISA). That list might not sound like much (or to some readers it might sound like too much), but a lot is happening here. IISA and AdJuggler have never caused problems in terms of performance or stability, but IIS and Cold Fusion have their moments. When IIS dies, everything stops, and when Cold Fusion stops, more than 80 percent of the site becomes unavailable. When you start considering virtual servers, more than just one Web site is at risk--if one is down, they're all down.