Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Microsoft Software Linux Apache

Red Hat/Apache Slower Than Windows Server 2003? 628

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."
This discussion has been archived. No new comments can be posted.

Red Hat/Apache Slower Than Windows Server 2003?

Comments Filter:
  • by dtfinch ( 661405 ) * on Saturday May 07, 2005 @02:21AM (#12460471) Journal
    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.
  • Easy (Score:5, Informative)

    by green pizza ( 159161 ) on Saturday May 07, 2005 @02:22AM (#12460475) Homepage
    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.
  • *ahem* (Score:2, Informative)

    by SynapseLapse ( 644398 ) on Saturday May 07, 2005 @02:24AM (#12460485)
    Veritest used webbench to do their testing.
  • by Evro ( 18923 ) * <evandhoffman@nospaM.gmail.com> on Saturday May 07, 2005 @02:26AM (#12460495) Homepage Journal
    Microsoft Windows Server 2003 vs. Linux
    Competitive File Server Performance

    Test report prepared under contract from Microsoft

    Executive summary
    Microsoft commissioned VeriTest, a
    division of Lionbridge Technologies,
    Inc., to conduct a series of tests
    comparing the File serving
    performance of the following server
    operating system configurations
    running on a variety of server
    hardware and processor

    At least they're up-front about it these days.

    Other Veritest-Microsoft fun:

    http://www.veritest.com/clients/reports/microsoft/ [veritest.com]
    http://www.microsoft.com/windowsserversystem/facts /analyses/default.mspx [microsoft.com]
    http://www.gotdotnet.com/team/compare/veritest.asp x [gotdotnet.com] - .NET versus Java

    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

  • Fair testing... (Score:2, Informative)

    by Anonymous Coward on Saturday May 07, 2005 @02:28AM (#12460505)
    Reminds me of this editorial on the G5's testing by Veritest. http://spl.haxial.net/apple-powermac-G5/ [haxial.net]
  • by cperciva ( 102828 ) on Saturday May 07, 2005 @02:36AM (#12460546) Homepage
    ...a specific ancient version of Red Hat

    This report was written in April 2003, according to the first page. They used the most recent version of RedHat available to them.

    This report may be two years out of date, but I can't see any signs of bias in its production.
  • by dtfinch ( 661405 ) * on Saturday May 07, 2005 @02:42AM (#12460576) Journal
    "we applied no additional patches and made no additional modifications to the Red Hat Linux Advanced Server 2.1 distribution used for these tests"

    I remember installing CentOS-3, based on RHEL3, on a server and having terribly slow disk performance with my raid adaptor. Running "yum update" to get the current patches yielded about a 10x speedup. Yet the Windows server gets a dozen or so undocumented registry tweaks.

    In the SSL comparison, they're using the fastest (though slightly less secure) choice of encryption algorithms in IIS and the slowest in Apache. They're comparing RC4+MD5 to 3DES+SHA1.

    And they decided to include ISAPI in the benchmarks without including the apache equivalent. All they test in apache is CGI. So again it's IIS's fastest option versus Apache's slowest option.

  • This is new? (Score:5, Informative)

    by louarnkoz ( 805588 ) on Saturday May 07, 2005 @02:43AM (#12460581)
    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?
  • Re:Easy (Score:5, Informative)

    by zeromemory ( 742402 ) on Saturday May 07, 2005 @02:57AM (#12460644) Homepage
    Furthermore, IIS performs better than Apache under light to moderate loads. Once you start moving to heavy loads, IIS begins to choke and eventually just can't handle any more clients. Apache just happily continues running.

    However, this might be more an effect of the underlying operating system than the actual server program. I haven't seen a comparison of Win32 Apache versus IIS, so I don't know.
  • by team99parody ( 880782 ) on Saturday May 07, 2005 @03:04AM (#12460668) Homepage
    "I assume you've never used IIS 6.0 .... Very very secure, easily arguable moreso than apache."

    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 [certcities.com]

    With IIS 6, everything changes. To start with, there's a new piece of kernel mode software: Http.sys. This driver, written by Microsoft, is responsible for receiving all IIS-bound TCP/IP traffic from the TCP/IP stack. Running in kernel mode gives the new driver a huge speed advantage
    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 [slashdot.org] as opposed to merely your anecdotal rumor:

    "Microsoft Internet Information Services (IIS) 6 with all vendor patches installed and all vendor workarounds applied, is currently affected by one or more Secunia advisories rated Moderately critical
    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"
  • by ArbitraryConstant ( 763964 ) on Saturday May 07, 2005 @03:10AM (#12460699) Homepage
    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.
  • by dtfinch ( 661405 ) * on Saturday May 07, 2005 @03:15AM (#12460719) Journal
    I didn't read the date, but I did manage to get in the first post, securing my position above the other +5's.

    I still see lots of biases, many of which can't be explained away as being the result of ignorance, laziness, or just knowing all the undocumented ways to tune windows.
  • by Anonymous Coward on Saturday May 07, 2005 @03:16AM (#12460728)
    RedHat 2.1 was fairly old by April 2003. They would have gotten a better benchmark from RedHat 9 machine.
  • by spuzzzzzzz ( 807185 ) on Saturday May 07, 2005 @03:27AM (#12460758) Homepage
    In the past I have seen people post blatantly false things which get accepted as true just because the mods are too lazy to check. So I thought I'd chime in here with links to some evidence to back up parent.

    1) The algorithms used in SSL are listed on page 33 of the pdf linked to. Both linux setups use 3DES+SHA1 and windows uses RC4+MD5 (as parent said).

    2) This [hn.edu.cn] page (found via google) has a table comparing ciphers about 2/3 of the way down. RC4 appears to be about 2-3 times faster than 3DES.

    3) This [ottawa.on.ca] email contains a comparison between MD5 and SHA1. MD5 appears to be 2.5 - 5 times faster than SHA1.
  • by 1u3hr ( 530656 ) on Saturday May 07, 2005 @04:01AM (#12460857)
    (if the above URL has a space in the word Immortal, don't blame me :) It looks fine in the comment, but the preview puts a space in. Anyone know why?)

    Trolls used to put long strings in which would stretch the page way over.

    Learn how to use HTML links; like ImmortalFumbles [pandora.be] that, which you code like

    <a href="http://users.pandora.be/vdmoortel/dirk/Physi cs/ImmortalFumbles.html">ImmortalFumbles</a>

    (Slashdot will iinsert spaces in this of course.)

    Also, your original URL had a trailing / which made it bad.

  • by MemoryDragon ( 544441 ) on Saturday May 07, 2005 @04:28AM (#12460915)
    No... for that date definitely not, but things have gotten much faster on the linux side since kernel 2.6
  • by Anonymous Coward on Saturday May 07, 2005 @04:33AM (#12460930)

    Speaking as someone who has quite some experience in cryptographic algorithms, I back up parent and grand parent. The benchmark is completely biased in that Veritest really ends up comparing 3DES+SHA1 with RC4+MD5. This unacceptable, I invite slashdoters to complain to Veritest:

    1001 Aviation Parkway, Suite 400
    Morrisville, NC 27560
    Tel 919-380-2800
    Fax 919-380-2899
    E-Mail: info@veritest.com
  • Re:May not be FUD (Score:5, Informative)

    by _defiant_ ( 120560 ) <stephen.butler@gmail.com> on Saturday May 07, 2005 @04:43AM (#12460961)

    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.


    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.

  • by julesh ( 229690 ) on Saturday May 07, 2005 @05:08AM (#12461054)
    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.

  • by jrumney ( 197329 ) on Saturday May 07, 2005 @05:21AM (#12461090)
    This report was written in April 2003, according to the first page

    Strange, they have a press release [lionbridge.com] on their website dated April 6, 2005 about the report being commissioned by Microsoft. Either Microsoft got ripped off by recycling an old report, or one of those dates is wrong.

  • by cperciva ( 102828 ) on Saturday May 07, 2005 @05:35AM (#12461121) Homepage
    Strange, they have a press release on their website dated April 6, 2005 about the report being commissioned by Microsoft

    Different report. That press release talks about Windows Server 2003 vs. RHEL 3.0 -- Microsoft must have asked them to produce a newer version of the report /. linked.
  • by dbIII ( 701233 ) on Saturday May 07, 2005 @05:40AM (#12461134)
    Flamebait? No, there are valid points as well as misconception. Being fanatical gets you laughed at for good reason. Some points are just ignorance which many people share, like this:

    7. You cannot admit that there is no professional printing capabilities in linux.

    I have a choice of Larson, SDI, Zeh and Easycopy as linux vendors to print to the 42 inch non-postscript printers in my workplace - very much a niche market but still covered.

    5. You cannot admit that you don't have professional usage of Linux outside server markets.

    Microsoft never entirely took over the workstation market, and linux boxes have been used as cheap unix workstations for years.

    13. You have problems in pointing a clicking, but have no problems in wading through cryptic scripts written by lunatics.

    Visual memory vs other kinds - some people find mousing through a lot of menus or the registry easier than flat config files, while I'm the other kind - valid point taken.

    23. You don't know commercial support in Linux is almost non existent.

    I run commercial software on 24 dual Xeon linux machines that costs almost as much each year as it did to buy the machines, but it is used to do things which make money for the company. It runs on solaris and AIX machines in the place as well. If I have a problem with it in the middle of the night there are people I can call to solve the problem - but normally emails with a one day lag due to time zones are good enough. As far as the company that sells the software is concerned we are a small operation - there are people with very big clusters out there.

    26. You are unaware that setting up servers on Windows takes couple of minutes while on linux, good luck playing with configuration scripts.

    Even from a disk image it take more than "a couple of minutes" to set up a windows server, even on something small like NT4.

    21. While the rest of the world moves on, you're stuck in a stone age technology that needs third party software to boot into GUI.

    It's unix - I know this!

    Third party software is everywhere, and it gave MS Windows the ability to get onto the net. Why re-invent the wheel when you already have something decent in the same group?

    25. You are unaware that linux has no terminal services (there is a lame one that no one uses), and commercial support for it is not happening.

    X is old news and VNC has been around for a few years too - in a wide variety of different situations both appear to still be a better solution than windows terminal services.

    29. You spend countless hours flaming people because

    Yes, but I'm doing it from work! However, Im doing it on a Saturday night while rebuilding a disk array - must be a masochist as specified above :(

    33. You keep ignoring the fact that thousands of linux servers get hacked every year

    Good point - all it took was one idiot giving all mail users shell access, turning on telnet and another idiot using "coffee" as a password and I had to rebuild a hacked box. You can set up an insecure system with just about any OS if you don't have a clue - there are plenty of people who use linux who don't have a clue, we all have to start somewhere - the learning curve is there, so if you don't know what to do you have to follow the docs or find out.

    17. You feel inferior deep inside but unable to admit it, you don't have a database as easy and powerful as Access.

    Have you ever seen other databases? MS Access vs most other databases is a similar comparison to MS Notepad vs most word processing software. Similarly you can still do decent work in MS Notepad, and sometimes that's all you need. MS Access doesn't even have a stable scripting language - I've learned two seperate scrip

  • by Anonymous Coward on Saturday May 07, 2005 @05:53AM (#12461163)
    The whole procession creation argument has been moot for years as I understand it, since both webservers have various caching mechanisms and so forth, even for CGIs.
  • by Jacco de Leeuw ( 4646 ) on Saturday May 07, 2005 @06:15AM (#12461217) Homepage
    One does not even have to be an expert in crypto. Simply type:

    openssl speed rc4 md5 des-ede3 sha1

    (Get OpenSSL here [shininglightpro.com] if you are using Windows). You will see that the first two algorithms are much faster, especially for larger blocks.

    I say this shootout is rigged.

  • by Anonymous Coward on Saturday May 07, 2005 @07:26AM (#12461374)
    FWIW here's the results of running this on my x86_64 machine:

    ~ $ openssl speed rc4 md5 des-ede3 sha1
    Doing md5 for 3s on 16 size blocks: 3229671 md5's in 2.98s
    Doing md5 for 3s on 64 size blocks: 2721010 md5's in 2.99s
    Doing md5 for 3s on 256 size blocks: 1858659 md5's in 2.99s
    Doing md5 for 3s on 1024 size blocks: 816811 md5's in 2.99s
    Doing md5 for 3s on 8192 size blocks: 131011 md5's in 2.99s
    Doing sha1 for 3s on 16 size blocks: 3225174 sha1's in 2.99s
    Doing sha1 for 3s on 64 size blocks: 2158082 sha1's in 2.98s
    Doing sha1 for 3s on 256 size blocks: 1167085 sha1's in 2.98s
    Doing sha1 for 3s on 1024 size blocks: 438103 sha1's in 2.99s
    Doing sha1 for 3s on 8192 size blocks: 63982 sha1's in 2.99s
    Doing rc4 for 3s on 16 size blocks: 46931949 rc4's in 2.99s
    Doing rc4 for 3s on 64 size blocks: 13189054 rc4's in 2.99s
    Doing rc4 for 3s on 256 size blocks: 3364646 rc4's in 2.98s
    Doing rc4 for 3s on 1024 size blocks: 861101 rc4's in 2.99s
    Doing rc4 for 3s on 8192 size blocks: 108304 rc4's in 2.99s
    Doing des ede3 for 3s on 16 size blocks: 3450802 des ede3's in 2.99s
    Doing des ede3 for 3s on 64 size blocks: 864132 des ede3's in 2.99s
    Doing des ede3 for 3s on 256 size blocks: 215751 des ede3's in 2.99s
    Doing des ede3 for 3s on 1024 size blocks: 53903 des ede3's in 2.99s
    Doing des ede3 for 3s on 8192 size blocks: 6752 des ede3's in 2.99s
    OpenSSL 0.9.7e 25 Oct 2004
    built on: Sun Dec 19 09:43:29 UTC 2004
    options:bn(64,64) md2(int) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr2)
    available timing options: TIMES TIMEB HZ=100 [sysconf value]
    timing function used: times
    The 'numbers' are in 1000s of bytes per second processed.
    type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
    md5 17340.52k 58242.35k 159136.02k 279737.28k 358943.85k
    sha1 17258.46k 46348.07k 100259.65k 150039.29k 175297.84k
    rc4 251140.86k 282307.51k 289043.41k 294905.49k 296731.23k
    des ede3 18465.83k 18496.47k 18472.33k 18460.43k 18499.13k
  • by Anonymous Coward on Saturday May 07, 2005 @08:52AM (#12461596)
    Incredible FUD. If you go to that Secunia page and compare, you'll see 2 graphs. While the graph for Apache has tons of security bugs, the IIS one is almost spartan. And if you scroll down, while you'll see Apache having to fix way more vulnerabilities, you'll see that the only unpatched vulnerability is a cross site scripting in the admin tool - so all you have to do is to turn off this tool and you're home free.

    Right now, it looks as if IIS *6* has a way better security track record than Apache.
  • by bundaegi ( 705619 ) on Saturday May 07, 2005 @09:11AM (#12461653)
    Does anyone know if any of the bits of the Silicon Graphics accelerating apache project were ever rolled into Apache 1.3.x or 2.x?

    Reading you link...

    Unfortunately the ASF rejected the work presented here and SGI terminated the project. It has a new home now on SourceForge, courtesy of SGI, and it seeks a new owner and a fresh start. Want Apache to run faster? Want to take a different approach to appealing to the ASF? Perhaps simply presenting the ASF with a different spokesperson would improve the odds of adoption. Apply to the current owner for project ownership or to sponsor me [repbot.org] to revive the project.

    Nonetheless, this project's aggressive optimizations make Apache/1.3 up to ten times faster and Apache/2.0 up to four times faster on the SPECweb96 [spec.org] benchmark.

    And in the FAQ [sf.net]:

    12. Will the ASF adopt the patches?
    We contributed the patches to the Apache Software Foundation but the ASF has refused to include the patches in future releases of Apache/1.3 or 2.0, citing "unnecessary" typecasts and complication associated with the warning-free 64-bit port, and incompatible license terms with the state-threaded MPM.

    So I presume... no :-) Thanks for the link anyway.
  • like noatime (Score:4, Informative)

    by diegocgteleline.es ( 653730 ) on Saturday May 07, 2005 @10:17AM (#12461916)
    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?
  • by InvalidError ( 771317 ) on Saturday May 07, 2005 @10:38AM (#12462018)
    I do not see why people should be authorized to conduct reviews and benchmarks of publically available products.

    Surprisingly (controversially?) enough, some EULAs forbid public criticism - I wonder if such clauses would ever be found valid in court, I seriously hope not - judges should declare void in whole any EULA that includes any anticonstitutional demands.

    Now that I think about it, I seem to remember that M$ used to include a non-comparison clause in many of its products' EULAs, this "licensed comparison" tells me it probably still does.
  • by wintered ( 75625 ) on Saturday May 07, 2005 @10:46AM (#12462060) Homepage
    Thats because the slashdot post is stupidly pointing at the wrong article. The real one can be found here:
    http://www.veritest.com/clients/reports/microsoft/ microsoft_IT_Pro.pdf [veritest.com]

  • by Billly Gates ( 198444 ) on Saturday May 07, 2005 @10:57AM (#12462106) Journal
    Actually I remember this 2003 benchmark. I read here and the editors forgot about it.

    Anyway here is the trick. First off IIS used ASP which does not use a mod interface like cgi scripts which means the engine can run in IIS itself. This makes IIS very fast.

    We have the same thing as ASP in the FOSS world called PHP. Zend is fast because the engine also runs in the same space as apache.

    Or I have seen in older 1999 benchmarks that MS will just use a static html to show how fast there platform is and ignore dynamic content. Also MS used a patch that was not made public which bound the I/O of 4 nic card to 4 cpu's in order to make I/O overhead very low. I think it may be standard in Windows2003 but its dumb tricks like these no one uses in a production environment anyway

    But I do not trust any benchmark that has a "Migrate from Unix to Windows" link on the right side of the report. Nooo its not biased

    However someone can point to a benchmark by the Linux kernel team and taking it as a grain of truth that its faster then net or freebsd. Its a dual standard.
  • by Gigs ( 127327 ) on Saturday May 07, 2005 @11:22AM (#12462218) Homepage Journal
    Prehaps you should look at the correct report http://secunia.com/product/1438/ [secunia.com] which shows 33% of Vulnerabilities are UNPATCHED and another 33% that you have to properly configure a workaround to fix... so ya I'd rather use the one that has all those patches that fix 86% of the issues.

    See so theres more to securing your box than turning off one tool, you have to know how to look up the issues which you can do easly on Apache's site right here: http://httpd.apache.org/bug_report.html [apache.org] and its linked right off the front pages of the web servers site.

    Then theres Microsoft's site for iis who's security link, links to this wonderful page http://www.microsoft.com/security/guidance/prodtec h/IIS.mspx [microsoft.com]. But whats that all you see is this message: "We're sorry, but there is no Microsoft.com Web page that matches your entry."

    Yup that gives you a warm and fuzzy feeling all over!
  • Figures (Score:3, Informative)

    by kelzer ( 83087 ) on Saturday May 07, 2005 @11:29AM (#12462256) Homepage

    They shut off access logging in IIS. As far as I could see, they left logging on for Red Hat. This means that lots of disk writes were being generated on Linux but not on Windows. As http request volume goes up in their tests, the RAID write-cache could eventually fill up (only under Linux), at which point the webserver starts blocking while waiting for disk I/O to complete.

    Figures that right after submitting this I see that they turned off access logging in Apache. Doh!

  • by Jacco de Leeuw ( 4646 ) on Saturday May 07, 2005 @01:40PM (#12462909) Homepage
    In the SSL comparison, they're using the fastest (though slightly less secure) choice of encryption algorithms in IIS and the slowest in Apache. They're comparing RC4+MD5 to 3DES+SHA1.

    I found another flaw on that same page.

    VeriTest also write that Windows 2003 was using RSA key exchange and Red Hat was using Diffie-Hellman (DH).

    But DH [wikipedia.org] is vulnerable to a Man-in-the-Middle attack so SSL uses RSA to perform the authentication.

    So Red Hat is doing RSA and DH, whereas Windows is doing only RSA!

    Using OpenSSL's ssltest program I noticed that DH+RSA was 50% slower than RSA:

    $ time ./ssltest -num 1000 -tls1 -cert server.pem -key server.key -c_cert client.pem -c_key client.key -cipher "RC4-MD5:@STRENGTH" -client_auth -server_auth -CAfile cacert.pem
    $ time ./ssltest -num 1000 -tls1 -cert server.pem -key server.key -c_cert client.pem -c_key client.key -cipher "EDH-RSA-DES-CBC3-SHA:@STRENGTH" -client_auth -server_auth -CAfile cacert.pem

    And I would not be surprised if Windows 2003 was using SSLv2 (faster and insecure) while Linux was using TLS1! Because that is another parameter that VeriTest is not disclosing.

Competence, like truth, beauty, and contact lenses, is in the eye of the beholder. -- Dr. Laurence J. Peter