Windows Server speeds along at 64 bit

In our Clear Choice Test of Microsoft's recently released 64-bit edition of Windows Server 2003, we found that when you employ optional, kernel-mode processing features, the operating system flies. When you don't, it runs a bit slower than other 64-bit server operating systems we've tested recently.

How we did it

Archive of Network World tests

Subscribe to the Network Product Test Results newsletter

These Windows 2003 Server x64 kernel options let certain processes run at the kernel code level - in our test case SSL certificate processing, caching and session handling. When you combine these options with mandated 64-bit hardware drivers and the vast amount of memory that a 64-bit processor can address, you can get some of the best performance we've seen on Intel/AMD architectures.

When we used kernel SSL processing, the number of sustained users climbed by 90% over 32-bit Windows Server 2003 processing. When compared with other 64-bit operating systems (Red Hat Enterprise Linux 4.0 [RHEL 4.0] Advance Server and Solaris 10), Windows Server 2003 x64 has a 15% to 20% performance advantage.

Without the kernel processing options, Windows Server 2003 x64 performed slightly under par with competitive 64-bit operating systems in our testing.

The downside to these performance gains is incompatibility issues in terms of the hardware Windows Server 2003 x64 can run on and some of the applications it can support.

The two generic AMD64 white-box systems we tested were incompatible with Windows Server 2003 x64. One wouldn't start the kernel or boot through a kernel load. The other had constant crashes after installation that seemed to be related to motherboard memory timing and additional SCSI hardware driver issues.

Two systems provided by Microsoft OEM partners - Polywell and HP - had no operational issues. Our primary test server was HP's four-way Opteron DL585 server. HP was the only hardware vendor with a full array of hardware drivers posted at Microsoft's Web site when the 64-bit operating system was released in April. Buyers are captive to OEM hardware providers for now. This obviously limits hardware choice: something we didn't experience with the 64-bit editions of Solaris 10, SuSE SLES 9 or RHEL 4.0.

Old DOS and early 16-bit executables (games, WordPerfect 5.1, and Lotus 123 Version 4) didn't work at all or worked initially but then halted abruptly. Microsoft employs a 32-bit emulator called WOW64 that is automatically invoked to run 32-bit applications. We typically saw equal or slightly better performance of these 32-bit applications on Windows Server 2003 x64 vs. 32-bit Windows Server 2003.

Interpreted code, such as an old Visual Basic application we'd written long ago, worked very well on this 64-bit engine. And we could find no difference in execution time of a Perl script running on Microsoft's Internet Information Server Web service in the 32- or 64-bit Windows environments.

Performance

We developed an SSL Transaction script using Spirent Communications' Web Avalanche to gauge the number of sustained SSL transactions over a 10-minute build cycle (see How we did it ).

The particular test ramps up the number of discrete user sessions, and then sustains sessions until the number of sessions dropped reaches 1%. Generating SSL sessions is CPU-intensive, and managing multiple numbers of sessions presents a good gauge of how many balls the server can keep in the air before it drops one.

We tested this script against Windows Server 2003 (both 32- and 64-bit versions) and compared these numbers against the 64-bit 2.6.7 kernel in RHEL 4.0 and Solaris 10 64-bit Edition. Both systems were running Apache 2.0.3 Web service with OpenSSL. We used default settings in all cases, except when we employed the kernel-mode SSL processing on Windows Server 2003 x64, as noted.

We took two sets of Windows Server 2003 x64 measurements: one reflecting the default kernel settings, and the other reflecting the aforementioned toggle that allows SSL to be processed by the kernel.

The difference between the results were startling, and proves the benefit of this simple setting. When we ran these tests on the four-way HP DL585 server, the operating system could sustain 288,471 sessions over a 10-minute period when the SSL sessions were handled at the kernel level. Microsoft states that the kernel lacks this setting by default, for backward compatibility reasons.

The Windows Server 2003 x64 native-kernel SSL session load was fast (207,202 sessions), but not as fast as RHEL 4.0 (251,024 sessions).

We also used two prior tests for comparison - the number of maximum open TCP sessions, which measures how many can be sustained, and the number of TCP sessions per second each operating system could support, to gauge how fast the system can ramp them up.

In the maximum TCP transaction test, Windows Server 2003 x64 bested RHEL 4.0 but fell behind Solaris 10. In the TCP transaction per second measurements, Microsoft beat Sun, but fell behind Red Hat.

Summary

On the surface, little has changed between Windows Server 2003 32- and 64-bit versions, but performance numbers accentuate the musculature of the hardware and memory-addressing space beneath. Windows Server 2003 x64 is a strong performer, especially when nominally tweaked to take advantage of kernel-level options.

However, driver and hardware support is weak enough that Microsoft requires buyers to tap OEM-related vendors for sourcing Windows Server 2003 x64 products. When these issues are resolved, we'll give it a stronger recommendation - because it's otherwise stable, fast and fully baked.

Henderson is principal researcher for ExtremeLabs in Indianapolis. He can be reached at thenderson@extremelabs.com.

Henderson is also a member of the Network World Lab Alliance, a cooperative of the premier reviewers in the network industry, each bringing to bear years of practical experience on every review. For more Lab Alliance information, including what it takes to become a member, go to www.networkworld.com/alliance.