Getting the Best Performance Out of BackOffice Server

Tune your server with the right applications, hardware, and software configurations

Configuring BackOffice Server for optimum performance is often more of a black art than an exact science. Each installation can have a different combination of applications and user loads that have a unique impact on the system's performance.

Microsoft makes different installation recommendations for BackOffice applications, depending on whether you buy the entire suite or individual component applications (e.g., Exchange Server, SQL Server). When you buy BackOffice components as standalone applications, Microsoft recommends that you install only one BackOffice application (e.g., Exchange Server) per machine. When you buy the BackOffice suite, the license agreement mandates that you install all the applications on one server. Using one server might add the requirement that the server be the Primary Domain Controller (PDC) and the do-all application server. Using one server for all these purposes isn't an easy task.

Let's assume that the system running BackOffice is the only server in a small (fewer than 100 users) office environment. Also, let's accept Microsoft's claim that file and print services require minimal system overhead, with print processing being the most CPU-intensive. Microsoft claims that on any reasonably fast system (Pentium Pro 200MHz with 128MB RAM or better), the overhead of a 100-job print queue remains below 10 percent of CPU utilization.

Let's look at the applications in BackOffice 4.0. Microsoft's research early in the product cycle showed that SQL Server 6.5, Exchange Server 5.5, and Internet Information Server (IIS) 4.0 were the most commonly used components of the server suite. My experience suggests that Proxy Server 2.0 also belongs in that group. (Site Server 3.0 is popular too, but its impact on server resources is minimal.) If the installation includes canned IIS applications that come with BackOffice, the server probably also runs Microsoft Transaction Server (MTS) 2.0, Microsoft Message Queue Server (MSMQ), and Index Server 2.0.

Setting Up the Hardware
When you examine performance, hardware is the first consideration. Microsoft's minimum hardware requirements for BackOffice Server are modest but also unrealistic in almost any situation where you use the server.

Given the nature of the BackOffice applications and today's low hardware prices, dual processors are a must. I'm not suggesting you rush out and purchase the latest 2-way Xeon server, but the primary BackOffice applications are well suited to multiprocessor systems. (For information about the benefits of a two-processor system, see Joel Sloss, "Microsoft SQL Server 6.5 Scaleability," January 1997.) Dual-processor, non-Xeon 400 and 450 MHz systems are priced competitively and provide additional capacity for your BackOffice server. Larger systems are available (4-, 6-, or 8-way) but aren't cost effective in the BackOffice suite environment. A dedicated server with the appropriate standalone BackOffice application installed is more suitable for applications that need that kind of power.

With 128MB DIMM memory costing less than $150, you have no reason to equip your BackOffice server with less than 256MB of memory. With SQL Server-based applications, the more memory available, the better, so you might want up to 512MB. More than 512MB requires a higher density memory that isn't as cost effective.

Using 100Mbps Ethernet in the server and either 10Mbps or 100Mbps switched Ethernet hubs prevents the network from being a possible performance bottleneck. The performance increase of going from 10Mbps to 100Mbps Ethernet easily justifies the slight incremental cost increase.

The most crucial piece of server hardware is the disk storage subsystem. Given the varied tasks of a BackOffice server, a high-performance storage system is necessary. Many entry-level server systems come with embedded SCSI controllers that you can upgrade to hardware RAID-capable devices. Traditional SCSI RAID vendors such as Mylex and DPT offer caching SCSI RAID controllers, and Adaptec has an entire family of multichannel SCSI RAID server controllers (i.e., the AAA-131 product line).

To optimize the drive system performance, dedicate at least two SCSI channels to storage devices and reserve one channel for low-speed peripherals (e.g., CD-ROM, tape backup). A dual-channel RAID controller with a low-cost single-channel SCSI controller will do the job. Don't mix fast and slow peripherals on the same SCSI bus, because this mixture slows the entire bus speed to the lowest common denominator. However, the latest generation of high-end SCSI controllers can help you work around the performance disparity problem. Another reason you don't want to mix fast and slow peripherals on the same SCSI bus is the commonness of SCSI bus resets that occur when you mix slower devices, such as tape drives, Jaz drives, Zip drives, and CD-ROMs, on the same bus with fast hard disks. You can see this phenomenon quite frequently in the NT Event Viewer System Log. Slow-up of the bus speed and bus resets negatively impact overall drive system performance.

Next, determine how many hard disks you need. For I/O-intensive applications, the general rule is that more spindles are more suitable. You'll get better response time from a pair of 9GB drives striped as a single 18GB partition than you will from a single 18GB drive. Also, take advantage of the hardware RAID capabilities, striping with RAID 0 for performance and RAID 5 for data security. The hardware RAID controller software/firmware lets you simultaneously do both types of RAID striping with different sets of drives. If you prefer to provide data security over performance, you can use RAID 0 (disk striping) rather than RAID 1 (disk mirroring). If you perform regular backups and can afford the downtime necessary to recover from a failed drive, RAID 0 is significantly faster.

In either case, the optimal disk configuration requires three physically separate groups of hard disks or hard disk partitions. The first group contains the system files and the NT page file. The NT page file needs sufficient capacity (at its minimal setting) to prevent the OS from having to increase its available swap space. This amount is usually equal to the size of RAM plus 11MB. When you are running Exchange Server, the recommended amount is equal to the size of the RAM plus 125MB. Although you can use one hard disk for this group, two disks give you the opportunity to either stripe for performance (RAID 0) or mirror for reliability (RAID 1). You can have multiple partitions within this group. This scenario is true for both the boot group (where NT lives) and the system group (where bootable—hardware-dependant—files are located). Never use NT's built-in software RAID, which is CPU intensive and inefficient, in any production environment.

Use the second group for your data and application files. For a good mix of performance with reliability, RAID 5 (stripe set with parity) is the best choice. If you have a system that supports hot-swappable drives, you must run RAID 5 for the most efficient utilization of the disk space and the ability to still perform hot-swaps. RAID 1 is another choice, but you'll pay a 50 percent disk-space penalty with this option. Here, you want as many spindles as possible: Spreading the drives across both channels of a dual-channel SCSI controller will give you the best performance.

The third group is where you put the log files that your server applications generate. SQL Server and Exchange Server both generate transaction log files, and you can configure IIS to do so. RAID options for this volume are the same as for group one. Dedicated groups for the SQL Server and Exchange Server log files are optimal, but only heavily I/O-intensive environments would notice the benefit of this configuration.

Installing the Software
After you've configured the hardware, the next step is to install BackOffice Server. Here, just install the components you need, and avoid installing the pieces you don't need. You can remove unwanted components later, but avoid ending up with unneeded services running in the background and using system resources. Select the most appropriate canned scenario from the scenario-based installation engine to get the configuration closest to what you need. BackOffice 4.5 includes a much-improved installation engine and selection of installation scenarios to set up intranet services and workflow automation.

Even if you don't plan to use IIS, you probably need to install it because the preferred method of remote BackOffice administration is via the Web-based administration tools, and without IIS running, this feature doesn't work. To optimize BackOffice and NT Server for top performance, you need to follow Microsoft's suggestions and configure NT Server to maximize throughput for network applications. Then, foreground applications, such as the console, get significantly reduced priority. As a result, the server will perform adequately, and remote management will work well, but local console response makes working at the server system untenable. This situation is likely if Index Server and the local console run at the same time.

Testing and Tuning Your BackOffice Setup
Microsoft offers tools that help you test and tune your BackOffice configuration. Although Microsoft doesn't offer a BackOffice tuner, you can test the individual applications in a close approximation of a live environment.

Exchange Server users might be familiar with Microsoft LoadSim. (For more information about LoadSim, see Greg Todd, "Understanding and Using LoadSim 5.0," January, February, April, May 1998.) This Exchange Server load-simulation tool constructs multiple Exchange Server clients that use Messaging API (MAPI). On the plus side, this tool is easy to use and to understand. On the minus side, LoadSim supports MAPI only and doesn't provide information about system performance if a significant percentage of users access their mail through Internet Message Access Protocol (IMAP) or Post Office Protocol 3 (POP3). Users might want to modify the standard LoadSim workload based on personal knowledge of their workload. For example, the standard LoadSim profiles don't allow for public folders, but many sites use them extensively.

After you run LoadSim, the Exchange Server Performance Optimizer is available. Using this tool is important because you can run it not only after an Exchange Server test but also when Exchange Server is running with SQL Server tests.

Tuning SQL Server requires skill. (To learn more about tuning SQL Server, see Brian Moran, "Tuning Your Database with SQL Trace," May 1998, and Kalen Delany, "Using Performance Monitor to Monitor SQL Server," June 1998.) Microsoft recommends the TPC-C benchmark from the Transaction Processing Council (TPC) as the proper tool to evaluate SQL Server platform performance, even when you run SQL Server as part of the BackOffice suite. You usually can obtain maximum performance in this benchmark only through serious massaging of the disk subsystem. For your system tuning, you'll use the TPC-C benchmark just as a load generation tool for SQL Server. The TPC-C benchmark applies stress to databases in the way that an online transaction processing (OLTP) application will. TPC also offers the TPC-D benchmark, which emulates a decision support system. Choose your test platform based on your planned use of SQL Server. (For more information about TPC benchmarks, see http://www.tpc.org.)

To place a load on IIS, Microsoft offers the INetMonitor tool. (For more information about the INetMonitor tool, see the white paper "Know Your Limit: The Capacity-Planning Tool Nobody Knows" at http://www.microsoft.com/workshop/server/feature/server042798.asp.) INetMonitor uses HTTP, POP3, Simple Mail Transfer Protocol (SMTP), and Network News Transfer Protocol (NNTP) to connect to the server to perform messaging tests against a properly configured Exchange Server (assuming you plan to support any of these protocols with Exchange Server). To examine the behavior of HTML and Active Server Pages (ASP), you need to use only the HTTP protocol.

Tuning your BackOffice server requires running all these tests at the same time and configuring Performance Monitor to track and log key data. (For an introduction to configuring Performance Monitor to examine patterns of disk usage, see Curt Aubley, "Tuning NT Server Disk Subsystems.") Also, you need to check the BackOffice server's network behavior to determine whether bottlenecks exist. However, in a normal scenario, a properly configured 100Base-T network adapter won't be the bottleneck.

After you begin to collect data, you can use the load simulators and benchmarks to increase the load on the BackOffice server until your system response time reaches an unacceptable point (e.g., greater than 1 second, greater than 3 seconds). This approach will give you an idea of the level of user interaction your BackOffice server can support. Tuning SQL Server and Exchange Server provides a good starting point for improving the performance of BackOffice Server, but temper individual application optimizations with the need for those applications to coexist on the same server. Keep your IIS code clean and stick to Internet Server API (ISAPI) and server-side scripting (rather than using Common Gateway Interface (CGI) scripts, which are notoriously CPU-intensive) to keep the performance of your BackOffice server at an acceptable level.