Spotting the performance leader on our charts isn't much of a challenge. Thanks to its 15,000-rpm drives with 8MB cache, the 2850 easily surpassed the other servers on our NetBench tests. NetBench mimics the behavior of clients accessing data on a server, and the 2850's disk I/O speed helped.

Another overall boost came from the 2850's use of 256MB of DDR2 memory in its integrated Dell PERC 4e/1 RAID controller. The Aberdeen, HP, and IBM servers all use standard SDRAM as a memory buffer in their RAID controllers. Since we used RAID 5 drive configurations (providing performance and data integrity), the RAID controller had a lot of traffic-handling duties.

The dual-channel, 400-MHz DDR2's theoretical memory bandwidth is roughly eight times that of the single-channel, 133-MHz SDRAM. A RAID controller using DDR2 can move much more data around more efficiently than a RAID controller with SDRAM. Because the integrated RAID controllers on all the servers connect through the PCI Express links built into the Intel E7520 chipset, memory on the controllers would be the site of any significant bottlenecks.

Though the Aberdeen Stirling 208S did not perform as well as the Dell server on the NetBench tests, it deserves kudos for turning in WebBench scores that are very close to the 2850's. We surmise that this similarity results from both servers using integrated Intel NICs. The IBM and HP servers use third-party chips connected to the motherboard chipsets. The Dell and Aberdeen servers' NICs seem better integrated with the rest of the E7520 chipset. For Web page service, the Aberdeen and Dell servers are neck and neck. But for high-availability environments, the 2850's other management and serviceability features make it a better choice.

How We Tested

All the dual-Xeon servers in our roundup came with Windows Server 2003 installed. Each server had 1GB of RAM, the data partition installed on a three-disk RAID 5 array, and two identical Gigabit Ethernet NICs.

We arranged the clients into two identical 30-node subnets, attached via 100-Mbps Ethernet to each NIC. We used two virtual LANs to connect the clients, the server NICs, and a controller machine. Each server was thus connected to a 60-node private LAN, comprising 60 identical 2.8-GHz Pentium 4 with Hyper-Threading clients. We used Windows 2003's TCP/IP stack for the networking protocol. This private LAN was not connected to any other network or to the Internet during testing.

WebBench 5.0 lets us measure the performance of Web servers as they handle requests from clients. We tested using the static and dynamic (simple CGI) test suites. The CGI interface lets Web server software interact with external programs, such as database engines, e-mail, and more. We set the performance option and file and print sharing to be optimized for applications. We turned off IIS logging and visit logs, and set performance to more than 100,000 hits a day. The site was not indexed; there was no application protection on the static-content directory, and the CGI-BIN directory was set as a virtual directory for dynamic content.

The Static test serves static HTML Web sites, including HTML code and GIF files. This test does not run any executables on the server, so the servers peak at a higher level than on the Dynamic test.

During a dynamic request, the client asks the server to run an ISAPI application that lives on the server. This application, or dynamic executable, creates HTML response data that the server returns to the client. Because the executable runs on the server, it uses processing resources on the server. WebBench provides a set of dynamic test suites, which are platform dependent. Dynamic requests constitute about 20 percent of the Web requests on the dynamic test, while the other 80 percent are static requests.

During an e-commerce request, the client asks the server to run an ISAPI application residing on the server, as well as negotiate a secure link using 128-bit SSL. The ISAPI dynamic executable creates HTML response data, which the server returns to the client.

Again, because the executable runs on the server, it uses the server's processing resources. The act of encoding and decoding secure communications also increases the load on the server's processors. E-commerce pages are like the check-out pages on e-commerce Web sites: The credit card transactions are secure, while the graphics and inventory computations are handled by static and dynamic content, respectively.

On our standard E-Commerce tests, 8 percent of the Web requests are secure and about 90 percent are static requests. Since SSL transactions heavily stress the CPU memory subsystem, we limited each client to one thread during e-commerce testing. On all three WebBench tests, about 2 percent of the load simulates Type 404 "Page not found" errors.

Considering what powerhouses these dual-Xeon servers are, we stressed them more than the other servers we've tested. We increased the number of engines running on each client to four. The clients themselves were not stressed beyond 20 percent CPU utilization during testing.

Keep in mind that because we used a slightly different testing methodology for this story, the WebBench E-Commerce numbers are not comparable to numbers we've run in previous issues. But since the static and dynamic ISAPI methodologies have not changed, the Static and Dynamic WebBench numbers can be compared with results in this past year's server reviews.

NetBench 7.0.2 measures how well a file server handles file I/O requests from 32-bit Windows systems. The clients pelt the server with requests for network file operations. Each client tallies how many bytes of data it moves to and from the server and how long the process takes. The client uses this information to calculate its throughput for the test mix. NetBench adds all the client throughputs together to produce the server's overall throughput in megabits per second. NetBench replicates the network traffic associated with file and print server use.