Slashdot Mirror
Red Hat/Apache Slower Than Windows Server 2003?
phantomfive writes "In a recent test by a company called Veritest, Windows 2003 web server performs up to 300% higher throughput than Red Hat Linux running with Apache. Veritest used webbench to do there testing. Since the test was commisioned by Microsoft, is this just more FUD from a company with a long history? Or are the results valid this time? The study can be found here."
Looking at the first page of the benchmark report, I see that they're using the exact same setup as in their highly contested samba benchmark, with a specific ancient version of Red Hat running on a specific hardware setup that version is known to have performance problems on. They could have at least tried a different server last time, or a modern version of Linux. Under fairer circumstances, who knows, IIS might have still won, but this rigged benchmark has nothing to offer us in deciding which server is faster.
Out of the box Apache doesn't do too well. But take some time tuning it, and your OS's TCP/IP stack, and you can easily outperform even Zeus. Read some of the tuning guides.
At least they're up-front about it these days.
Other Veritest-Microsoft fun:
http://www.veritest.com/clients/reports/microsoft
http://www.microsoft.com/windowsserversystem/fact
http://www.gotdotnet.com/team/compare/veritest.as
In short, this is a company paid by Microsoft to make reports/whitepapers that make Microsoft look good. Nothing wrong with that as long as everyone's aware
rooooar
The web page says it was published May 5, 2004, i.e. a year ago. The report itself is dated from April 2003. The test was done using RH advanced server 2 and Windows 2003 RC2, i.e. a pre-release version. Since then, both RH and Microsoft have published new releases, for example the service pack 1 of Windows 2003. Why is this posted now?
You're shooting for a Funny mod, right? The biggest "advancement" in IIS 6 is that instead of IIS 5.X that that ran 100% in user-mode, IIS 6.X runs as a kernel module
Which is a cute trick for gaining performance at the expense of security (kinda like the various Linux kernel-web-servers like khttpd)."But why would you believe that? I mean it's not like it's easy to find out.."
Indeed you are correct that it's not easy to find out. Leading security sites all report that it is NOT more secure as you allege. For example, the current rating of IIS 6report from Secunia, (one of the top couple security companies as opposed to merely your anecdotal rumor:
In contrast, Apache 2.X has the much better rating: "Apache 2.0.x with all vendor patches installed and all vendor workarounds applied, is currently affected by one or more Secunia advisories rated Less critical"300% is pretty hard to believe.
Apache was never optimized for serving lots of small, static files so I can easily believe it falling behind in some benchmarks, but not 300%.
It doesn't take much computer to saturate a lot of bandwidth, which is why most people don't care, but big sites will often have a Zeus (or similar) server set up for serving images precisely because Apache isn't as good for that. But you've got to be huge before you get to that point.
Dynamic content put Apache where it is. It has the support, the tools, the libraries, and the widespread expertise to do dynamic content pretty damn well. It's not better than everyone at everything there either, but it's a very good solution for most cases.
I rarely criticize things I don't care about.
You are mistaken on some Apache concepts and how threads (?used to?) work on Linux.
This is because for each request, Windows must create a new process (the CGI program), and destroy the process when the request is complete. While the execution time is low, the process management overhead dwarfs the actual page runtime, because Windows doesn't do that sort of thing quickly. This is why CGI has long been blacklistedon Windows systems by good web devs, and this is one reason that Apache 1.x was such a dog on Windows. Apache 1.x creates a new Apache process for each request.
No.
Now Linux, on the other hand, creates processes about as fast as it creates threads, which is to say, really damn fast.
Yes, but only because pthreads does this by creating a new process (that just happens to share some things with its parents, like address space). Ergo, creating threads is just as fast as creating processes because they are nearly the same thing.
The NPTL in 2.6 might have changed this, but I have not read the docs yet.
Yet Apache is still back here creating a process or thread for each and every request (note that there are some ways to speed things up. FastCGI comes to mind, but I don't want to get into the gory details that I don't know enough about). This is not the brightest way to do it in terms of performance, but then, Apache appears to have been designed for universality and configurability over raw throughput.
No, Apache does not create a new process for each request. It creates a pool of child processes which sit waiting for requests. The parent monitors this pool and creates new spare children when too many child processes are busy. This way, most of the time a request comes in there is already a child process sitting idle waiting for work.
CGI does indeed require forking a new process, but there are already great ways to handle this. mod_perl, mod_php, mod_python all do it by embeding the interpreter inside the server. FastCGI keeps a version of the program running (much like apache does with its spares).
You are correct in that your description isn't the brightest way to do things. That's why operating system designers solved these problems years ago.
For static content, again, Apache creates a new process or thread for every request (with some exceptions). If you'll forgive a bit of an oversimplification, it's like writing a program that prints text to the screen. One program calls printf() in a loop. The other program executes a second program which itself displays just one line, and runs that in a loop.
Again, no. Apache will usually not need to create a new process or thread for every connection. The correct analogy would be the other program spawning the required number of children, and then asking them to all printf at the same time.
Why couldn't IIS be faster than Apache?
It could be. However, this test is severely flawed in that they performed registry level optimisations to the Windows setup, yet equivalent optimisations that are well documented for Linux were not performed. Therefore, we don't know.
Surprise, they enabled DisableLastAccesS on windows but did not mounted linux filesystems with noatime
noatime disables the update of the "last accesS" field of files, and improves the performance a lot for some workloads. If you check the latest article about the kernel.org servers, they found that they reduced the system load to the half by just using this option
This analisys is biased. Who cares, anyway?