Filesystems

(LinuxWorld) — Microsoft funded and released a new set of benchmarks to follow the debut of its often-renamed Windows 2003 Server. The boys in Redmond are proud as punch of their new baby, whatever its name. They would have the world believe that Windows 2003 Server is twice as fast as Linux, at least when it's used for file serving.

Microsoft hired VeriTest to conduct benchmarks using hardware and software configurations provided by Microsoft. VeriTest shares Microsoft's penchant for name changes. VeriTest used to be known as ZD Labs, and has also been known as eTesting Labs. The benchmark results VeriTest produced for Microsoft showed Windows Server 2003 to be faster than Red Hat Linux/Samba on both uniprocessor and SMP HP servers — a stunning 66-to-95 percent faster, at that. Given the many configuration options for Linux, Samba, and Windows, I had questions about the validity of VeriTest's results.

Reactions from the Samba team

I spoke to Jeremy Allison, head of the Samba team, to get his reaction to the benchmarks. Allison provided a few insights into the test configurations that don't leap out at me because they are hidden away in appendixes to the benchmark document. Allison feels the hardware configuration Microsoft chose is substantially responsible for the outcome.

Benchmarks aside, I asked Allison what he would tell someone who approached him about wanting to save money by moving from Microsoft servers to a Linux/Samba solution, but was also interested in how they compared in performance. Would he say, for example, that the performance of the two were comparable? Or that Linux was slightly slower? That it was slightly faster?

Allison minced no words about it. "I would say that actually we are faster." But then he added this caveat, "In all the earlier benchmarks, we have been. Before I would say that against (Windows Server) 2003, I would want to have the chance to repeat this benchmark. I'm hoping that we do get the chance."

If you look through the various benchmark results listed on Dan Kegel's NT-vs.-Linux benchmarks page (the URL is provided in Resources below), you'll see what Allison means. In September of last year, Red Hat Linux Advanced Server 2.1 bested Windows 2000 Advanced Server in both performance and price/performance in a TPC/C comparison.

In June of 2001, Ziff-Davis/eWeek compared Web-serving on Windows 2000/IIS and Red Hat/Apache, Red Hat Apache with TUX, and Red Hat/TUX. Windows 2000 just barely nosed out Red Hat/Apache, but against TUX, Red Hat's Web server for SMP machines, it was hopelessly outclassed. TUX scaled to more than twice as many clients as the Windows machine.

For those benchmarks, by the way, technicians from Dell, Microsoft, and Red Hat were present and assisted in setting up and tuning the systems. That's definitely not the case in the VeriTest benchmarks. As Allison put it, referring to the most-infamous benchmarks of the past, "It's Mindcraft all over again."

RAID 0, Windows 1

Allison pointed out the heart of the problem in the most-recent benchmarks immediately, though it was hidden away in Appendix B of the 21-page document.

"Note that they used RAID 0, not RAID 5," he said. "Linux RAID 0 performance isn't terribly good for software RAID; (it's) much better with software RAID 5. On Windows, performance with RAID zero is very good."

(Editor's note: The PDF file states VeriTrust used hardware RAID on both systems.)

He strengthened that argument by pointing out the throughput-performance graphs that are part of the benchmark results. "If you look at the curves in the benchmarks, what is really really obvious is that Samba, or the kernel, isn't running out of steam," Allison said. "What's running out of steam is the disk subsystem."

The graph below, taken from the VeriTest benchmark, illustrates the problem.

RAID 0 wasn't the only poor choice for Linux in the tests. "They used ext3, which is one of the slowest filesystems on Linux," Allison said. "In a real comparative test, you would use XFS, you would stripe it appropriately, doing exactly the same thing for the Windows system, of course. Then you would put the journal log on a separate device."

Allison believes those two changes alone — changing from RAID 0 to RAID 5 and from ext3 to XFS — would end the I/O bottleneck that flattened Linux's performance-curve very early in the VeriTest benchmarks.

More tweaks

Allison's analysis does not end there. He also pointed out ways in which the Windows system had been tweaked to make it perform at its best. As the benchmark document clearly states on page 7: "For the File server performance testing using Windows Server 2003, we performed a series of operating system and testbed client tunings as specified by documentation provided from Microsoft."

Part of the tuning that Microsoft provided VeriTest, for example, was a registry setting that turns off the standard Windows 8.3 file-naming convention. Another tweak was made to TCP stack on the client machines. Yet another tweak was made to the buffer-cache pool on the server. Obviously, Microsoft invested considerable time and effort in finding the best possible configuration. On the Linux side of the table, VeriTest relied only upon their own in-house expertise, bolstered by a couple of books and Internet searches.

Allison concluded our brief visit by stating, "I'm not saying that we, the Samba team, could have produced the same benchmark going in the opposite direction." Allison clearly wants to do his own benchmarks to straighten the record. Maybe Red Hat or another Linux vendor will step up and provide the hardware and software required to do just that.