Novell's SLES9 vs. Microsoft's Win2K3
A Windows Domain Control & File Server Comparison
"Out of the Box" File Serving Performance
One of the main issues you want to look at when purchasing Server software and hardware is how well it will perform as a file server, especially on a Windows based network where you have to deal with "user profiles".
Windows User Accounts Overview
On a Windows NT/2k/XP based network, every user will have a domain user profile. The profile stores all of the user's settings, Internet bookmarks, etc. and how you implement profiles is dependent on how the users work on the network and how much control you want over the users. There are 3 basic profile types you can use. Local, Roaming and Mandatory profiles.
(In a nutshell) Local profiles are simply stored on the local machine that the user is on and if they adjust a setting on the machine, it will not be changed on any other machine. Roaming profiles are stored on a central server and will be downloaded to the local machine every time the user is logged on and will also be copied back to the server when the user logs off. The good thing about roaming profiles is that if you adjust something on one machine, the other machines will also use that change. Finally, Mandatory profiles are basically roaming profiles that the user cannot change, they will be copied to the local machine on log on, but will be deleted on logout.
In theory, roaming profiles are the way to go for most networks, not only because the users do not have to use the same computer to retain their settings, but because it also inadvertantly gives you a backup of every user's profile and the profiles are stored in a central location. Unfortunately, when roaming profiles are implemented they can be a huge performance hit on your servers, especially if the users login or logout at the same time.
Now that you somewhat understand why file sharing performance can be very important for logins as well as for sharing files, lets get on to the the benchmarks.
Benchmarking Enviornment
The computer hardware used in benchmarking both Operating Systems consisted of :
AMD Athlon XP 3000+ (400mhz FSB)
1 GB DDR Memory
Gigabyte 7N400 Pro2 Motherboard (nforce 2)
Adaptec 29160 SCSI Controller
40 GB Seagate Cheetah Hard Drive - 15,000rpm - latest version
Gigbit Network Controller (on motherboard)
NVidia Geforce FX 5600 (as if this matters)
To keep the number of variables to a minimum, I specifically chose hardware that has mature drivers on both Windows and Linux. I also stayed away from implementing any type of RAID in this test setup. Most servers should use a RAID implementation, but for this comparison I decided to only test the software on a solid hardware foundation for both Operating Systems.
For the clients I utilized a computer lab which consists of 20 NT4 Workstation computers ranging from Intel Pentium 3 - 733mhz computers to AMD Athlon XP 2600+ computers. Most workstations are directly connected to the same HP Managed switch as the Server, although 5 were connected to a small Dlink switch, which in turn was connected to the HP switch (Surprisingly, I did not notice any performance hit on those 5 computers).
For both Server Operating Systems, I simply used the default installs, loaded updated hardware drivers, updated each OS utilizing Windows Update and YaST Online Update, then set up a simple share that the Windows Clients could access. These results are what you will get "out of the box" for both products. I am sure that both products could be "tweaked" to improve the benchmarking scores, but in my experience, most network deployments will mostly stick to the default install, which is then customized to their network and domains.
legal stuff - The benchmarking suite I used was NetBench from Zonelabs. NetBench(R) is a registered trademark of Ziff Davis Media Inc. or its affiliates in the U.S. and other coutnries. PC Magazine's NetBench(R) version with the standard system Test Suite DM.TST, with the following adjustments - The number of clients were changed from the defaults to the following - 5 clients (using 5 computers) - 10 clients (using 10 computers) - 15clients (using 5 computers) - 20 clients (using 20 computers) - 25 clients (using 5 computers) - 30 clients (using 10 computers) - 40 clients (using 20 computers) - 50 clients (using 10 computers) - 60 clients (using 20 computers) - 80 clients (using 20 computers) - 100 clients (using 20 computers). The test was performed without independent verification by VeriTest testing division of Lionbridge Technologies, Inc. ("VeriTest") or Ziff Davis Media Inc. and that neither Ziff Davis Media Inc. nor VeriTest make any representations or warranties as to the result of the test.
As you can see I only used a total of 20 computers, which in turned emulated up to 100 computers. This may have had a impact on the results, but when I tested 5 computers emulating 20 computers against 20 computers, the numbers were pretty much the same, so I assume this did not matter much.
Results
The throughput graph displays how much data the server can "dish out" with the number of clients requesting data. The response time shows how quick the server is able to provide the data to the clients depending on the number of clients requesting data at the same time.
As you can see from the graphs, Novell's SLES9 pretty much more than doubles the performance of Microsoft's Windows 2003 Server on the exact same hardware in both categories. This is very, very impressive, and shows the strengths of both Samba and the Linux kernel, as well as the attention to detail Novell/Suse employees had when implementing the default settings.
With this hardware Windows 2003 Server seems to max out on performance at approximately 30 Clients with a throughput of about 135Mbps, where SLES seems to max out on performance at approximately 60 Clients with a throughput of about 255Mbps. The response time is also about twice as fast on SLES9 than on Win2k3 on the same hardware. So, in theory, you can handle twice as many clients on the same hardware using SLES9 compared to using Windows 2003 Server. For the actual numbers you can view the OpenOffice.org calc sheet here.
For this article I tried different ways to improve the scores for Windows 2003 Server without touching the default install (which is what I am testing). This is why I only used Windows NT 4 Workstations since they provided better performace than 2000/XP did. I also ran the benchmark 5 times for Windows 2003 and took the best times from each benchmark (i.e. I took the best 5 computer results, the best 10 computer results, etc.), whereas with SLES9 I ran the benchmark 3 times and randomly chose one of the results (and it wasn't the best one).
After running the benchmarks for the article, I also tried to search the Internet for tweaks to the default install to improve Windows 2003's performance, and after applying all the tweaks I found, all I could get was maybe a 10-20% increase in performance. If anyone knows how to really increase the performance of Windows 2003, let me know and I will create an addendum to this. Apparently there has to be some magic voodoo you can do to gain performance on Windows 2003 Server since Microsoft continually states that Windows 2003 outperforms Samba.
Performance Leader: SLES9
While implementing this benchmark, I found a few interesting facts about our network. First, if you run Norton Antivirus on your workstations, you are definitely taking a massive hit. On the NT 4 machines, the usual throughput until the server gets maxed out should be around 6Mbs, with Norton Antivirus enabled it dropped to just over 1Mbps. On the 2000/XP machines I was going to use, the hit was not as dramatic, but it still dropped from 5-6Mbs to just over 3Mbps.
Another issue I found interesting with the NT Workstations was the fact that the 3com 3c905 adapters performed horribly with the MS drivers included with Service Pack 6a, but an install of the latest drivers from 3Com fixed the performance issue.
Compatiblity
In today's software world, one of the issues you need to consider when implementing a network system is the softwares compatibility with other software. This not only means, does the software work with the given solution, but in many cases, is the software supported on the given solution.
Unfortunately software companies do not like to take the blame for any malfunctioning software, even if they are responsible they like to "pass the buck". I don't know how many times I had to deal with software support personnel telling me that the cause of the error has to do with the server software not being supported, then still having the problem after transferring everything to a "test network".
At the current time, this usually means that if you are not running a Microsoft Server, many software companies will not support the installation. So, when deciding upon the server platform, it is a good idea to find out what software the users are running to find out if the companies have a "servers supported requirement". Most software companies will usually support both Microsoft and Novell Servers, and I am assuming that they will also support Novell's SLES9 servers.
On the flip side, Microsoft Servers do not interact very well with other vendor's servers. An example: If you are going to use Active Directory, Exchange Server, or most of the other servers Microsoft provides, do not even think about using anything but a Microsoft DNS server. This is why I really got a kick out of Novell's Ad - "Random Access: Freedom to choose SUSE Linux or any other software you damn well please." - It kind of hits the nail on the head.
Before you implement any server solution, be sure to ensure all applications will at least run properly (be supported if needed) on the chosen architecture. Also keep in mind that if you do choose a Microsoft solution, be sure to calculate the expense of replacing any servers that might interfere with the functioning of Windows Server 2003.
Compatibility Leader: Win2k3
