Windows Server 2003 and SQL Server 2000 scale to new heights
As Microsoft’s 64-bit OS and database rise high above the 32-bit platform, pieces are still falling into place
It’s simple, really: Bigger is better. Compared to a 32-bit system, a 64-bit system offers a larger memory address space for applications, a wider bus into the underlying memory hardware, and superior floating point precision to better massage all those terabytes as they pass through the various “double-wide” registers of a 64-bit CPU. In real-world terms, 64 bits means bigger databases, faster transaction times, and more robust number crunching.
Veteran datacenter hardware vendors Sun Microsystems, IBM, and Hewlett-Packard have been doing 64-bit computing for years, providing highly scalable but inherently proprietary platforms complete with complex installation procedures and mainframe-like pricing. Now the barbarians are at the gate, threatening to cut into Unix’s proprietary high margins. The march toward 64-bit commoditization began with Linux systems built on AMD Opteron and Intel Itanium hardware. In late April of this year, Microsoft joined the wars with Windows
Server 2003 Enterprise Edition and SQL Server 2000 Enterprise Edition for 64-bit Itanium systems.
Is the 64-bit Wintel era close at hand? To find out, I compared performance of 64-bit Windows Server 2003 and SQL Server 2000 to the 32-bit versions of the same software, using similarly configured Itanium 2 and Xeon dual-processor servers from IBM — the IBM eServer x450 and IBM eServer x335, respectively. I not only tested raw transaction performance in two- and three-tier client/server scenarios, where the results were promising, but also ran tests against a number of underlying components, trying to determine how far Microsoft has gone in optimizing all of the Windows and SQL Server code for 64 bits. Here I discovered that Redmond still has work to do.
But that’s not all. The 64-bit versions of Windows and SQL Server are missing several features of their 32-bit counterparts, hindering their usefulness and manageability (see “64-bit Still Under Construction,” page 51). In particular, the lack of a 64-bit version of the .Net Framework make the new platform unsuitable for virtually any applications aside from massive in-memory databases and ultra-precise floating point calculations. Until Microsoft makes a 64-bit implementation of .Net available (a beta is scheduled for Spring 2004) Windows for Itanium won’t be a viable platform for running Web applications or Web services.
Clouding the future further is the immaturity of Intel’s 64-bit IA-64 architecture, as embodied by the Intel Itanium and now Itanium 2 CPU platforms. IA-64 is hampered by a slow clock frequency (top-end is still only 1.5GHz) and a relatively complex development model, which requires programmers to pass their native IA-64 code through several stages of post-compile testing and tuning. Considering the dearth of native applications, and an unfamiliar development model that throws the quality of available applications into question, most IT shops would be wise to take a wait-and-see attitude toward Windows on Itanium.
Pipes and Protocols
Experience teaches us that the real showstopper flaws rarely pop up where you expect them. Rather, they tend to trip you up when you’re doing the less glamorous stuff, like managing data flow and scripting routine process automation. So, in addition to focusing on the massive scalability potential provided by the high memory bandwidth and multi-terabyte address space of the IA-64 architecture, my tests zeroed in on the software “plumbing” that glues the various pieces of the new platform together.
