In the dog-eat-dog world of commodity, Intel-based servers, IBM’s eServer xSeries 450 is a greyhound. As is often the case with such purpose-bred creatures, IBM’s lean and svelte rack-mountable 64-bit solution sacrifices computing heft (lots of memory and expansion possibilities) in favour of another worthwhile quality — a smaller footprint.
In fact, the xSeries 450’s 4U rack space requirements are one of IBM’s primary marketing bullets for this system, which is matched only by IBM’s x455 and rival HP’s Integrity rx4640 in delivering a four-way capable IA-64 system in a 4U form factor. HP also offers a four-way IA-64 system in a much larger 7U package, the Integrity rx5670, delivering greater memory expansion (96GB vs 40GB for the x450 and 56GB for the x455) and using speedier PC2100 Dual Data Rate (DDR) Error Correcting Code (ECC) memory (the xSeries use slower ECC SDRAM).
IBM makes up for some of these shortcomings by innovating in other areas, such as fault isolation. The x450’s intuitive Light Path Diagnostics feature makes it easy to trace a fault to its source, with internal LEDs leading you from the front panel display straight to the failing component.
This process is further aided by the modularity of the xSeries. Major functional areas (CPU, memory, I/O) are grouped into quick-release component blocks that make it easy to gain access to the innermost regions of the chassis. In fact, the system is so well laid out, and the on-chassis diagrams so straightforward, I was able to break the entire server down to its base frame in just a minute or two without any tools.
Of course, the xSeries also ships with the core redundancy features that enterprise IT customers expect: dual hot-swappable power supplies; hot-swappable cooling fans; six hot-swap/add PCI-X slots (HP offers nine in the rx5670); Chipkill memory fault isolation; and Active Memory technology, which IBM claims is like RAID for memory. In fact, you get nearly everything you’d want in an Intel-based server. My only major gripe is with the memory subsystem: not enough expansion and (potentially) reduced performance with SDRAM, which IBM denies.
Itanium vs Xeon
Whether or not the slower SDRAM was a factor in my test results is difficult to say. The xSeries 450’s performance was adequate but unremarkable under 64-bit versions of Windows Server 2003 and SQL Server 2000 in my tests. In two- and three-tier client/server database simulations, the x450, with its two 1.5GHz Itanium 2 processors, outpaced a similarly equipped Xeon server, IBM’s xSeries 335 with dual 3.06GHz Xeon DP processors, when running identical workloads. However, the margin of victory was small — just 5-8 per cent.
Due to the relative immaturity of the 64-bit Windows Server 2003 code base, I hesitate to blame any performance shortcomings on a particular hardware implementation. However, the x450 demonstrated similarly ho-hum performance in separate tests under Linux, where it was equalled or outpaced by the dual Xeon x335 in a number of tasks. A MySQL benchmark showed the x450 lagging behind the dual-Xeon x335 in several tests, notably table inserts. Overall, the MySQL tests showed the x335 besting the x450 by about 10 per cent on average, whereas Samba filesharing tests showed the x450 faster by about 8 per cent.
The xSeries 450 achieves IBM’s stated goal of delivering Itanium 2 capability in minimal space. But along the way, Big Blue was forced to make some trade-offs in terms of expandability and component selection (SDRAM). It may be too early to tell how well the xSeries 450 will perform with a well-tuned software stack. What is certain is that IBM has done its homework in making the x450 easy to maintain, with innovative technologies such as Light Path Diagnostics helping to differentiate this offering in an increasingly crowded IA-64 field.
How I tested
My tests were designed to compare performance of 64-bit Windows Server 2003 and SQL Server 2000 on Intel Itanium to 32-bit versions of the same software on Intel Xeon hardware. IBM supplied both systems. The 32-bit system was an IBM eServer X-Series 335 with two 3.06GHz Xeon DP processors and 512KB of L2 cache. The 64-bit system was an IBM eServer X-Series 450 with two 1.5GHz Itanium 2 DP processors with 256KB of L2 and 1.5MB of L3 cache. MPC ClientPro 545 Pentium 4 PCs served as the test clients. The systems were stitched together via a NetGear GS108 full-duplex Gigabit Ethernet switch.
I used a combination of off-the-shelf tools and custom scripts to create the nearly 70 unique workload combinations that made up my 64-bit test methodology. These included the CSA Research Benchmark Studio simulation and testing framework (for two- and three-tier client/server workloads) and a simple Data Transformation Services (DTS) execution shell I cobbled together using Microsoft’s Visual Studio Enterprise Edition 6.0.
For the two-tier scenarios, I used Benchmark Studio’s ADO Stress workload simulator to drive OLE DB and ODBC-based transactions against both of the IBM eServers. I began with a single simulated client session and then gradually scaled the workload to include additional clients and an increasingly larger data set. In addition to varying the ActiveX Data Objects provider, I also experimented with different combinations of network libraries (TCP/IP vs Named Pipes) and transaction support (read, write, read/write, and none). Finally, I varied the read/write ratio for the workloads, beginning with a lightweight (single client) scenario with read-only transactions (no write operations) to a more demanding (10 clients) simulation with 100 per cent of the transaction data written back into the database.
The three-tier scenarios mimicked the two-tier tests, except that the workload generation tasks were handled by an Active Server Pages script running directly on the server. I used the ASP Stress module of Benchmark Studio to simulate from five to 50 concurrent Web browser connections, each driving a separate session of the ASP script (adostress.asp).