some comments on Chris's latest work http://www.webperformanceinc.com/library/reports/windows_vs_linux_part1/index.html

Thought I'd just post these to the group since others may have some 
thoughts that I missed....

Some comments (unofficial, my own opinion's only, but I'm not hiding 
affiliations):

see:

1. 
http://www.webperformanceinc.com/library/reports/windows_vs_linux_part1/index.html
2. 
http://www.webperformanceinc.com/library/reports/windows_vs_linux_part2/index.html


Disclaimers:

Chris, quoted comments are here for context "fair use" -- please don't 
sue me :-)

Bias -- I'm a died in the wool UNIX geek.  All my servers are Linux and 
my latop is a powerbook.

"
Server Software

The two OSs utilized during this test were Microsoft Windows Server 2003 
("Windows"), and CentOS 4.2 x86_64 ("Linux"). With Windows installed, it 
was permitted to use Windows Update to install the most recent service 
packs and updates as of November 16, 2005. Our Linux copy was installed 
via CDs burned from the publicly available ISO images. The YUM Updater 
was then allowed to update all installed packages to the latest stable 
versions as of November 15, 2005.
"

I would have liked to have known what kernel that is.  Google wasn't 
very definitive, but I'm going to assume 2.6.9.

Hardware:
"
Processor  	One Intel Xeon 2.8 GHz with HT Technology
Memory 	512 MB
Disk Drive 	One 40 GB SATA disk drive
Ethernet 	One 1 GbE ethernet interface.
"

This is a pretty underpowered system for most enterprises today.  I'm 
also under-enthusiastic about a single processor system test.  The 
reason being is that a big difference that I see between VMs is the 
performance of parallel garbage collection.  Moreover, if the license 
permits it (and it probably doesn't) I'd have enjoyed seeing a JRockit 5 
vs JDK 5 vs JRockit 1.42 vs JDK 1.42 matrix of effect on Linux and 
windows.  I realize it is a tall order.  At JBoss most folks in the know 
preferred JRockit in the 1.42 era, but there is a lot of debate still in 
the JDK 5 era.  The people who do microbenchmarks are generally happier 
with JRockit5 but under memory constraints with low thread contention 
I've had a lot of luck with JDK 5.  It is not yet clear in my mind which 
one to recommend as a rule of thumb beyond motivational analysis: "Intel 
writes JRockit and Sun uses AMD processors in their servers...".  It was 
generally clear in the 1.4.2 days to recommend JRockit except for 
64-bit.  (IBM's JDK has a retro garbage collector that makes it slow).


"
Results

With our servers configured as we have outlined above, we may now 
proceed to examining the results of the test. The servers appeared to 
quickly hit a VM memory restriction. Results upon remedying this error 
should become available in part two of this article. The interesting 
aspect of this test is that we see the servers behave quite differently 
when forced to serve beyond their capacity.
"

Are you sure?  It would be nice to see the gc.log for this test.  Should 
be pretty easy to see.  It would also show us whether the VM elected (or 
you do) to use the parallel collector with hyperthreading.

I'd also like to see a server.xml.  You can set the TCP backlog for the 
connector.  I'm curious if thread contention was also an issue (did you 
up the number of threads and idle threads?).  Not to defend Windows, but 
I'm curious if this is just a default setting difference (lower backlog 
on Windows) or just a "cost of lack of idle threads" type thing. 
Turning away traffic "connection refused" means no thread picked it up 
AND you run over your TCP backlog setting.

"
Servlet Container Preparation

Tomcat was installed following the procedure outlined in the earlier 
edition of the Servlet Report. The only difference made here was to 
increase the JVM memory limits. Since each server was equipped with 512 
MB of RAM, the new memory configuration setting was arbitrarily chosen 
to have a 200 MB initial size, with a maximum of up to 384 MB. Under 
Windows, the settings were entered directly into the configuration 
manager applet installed with Tomcat. Under Linux, the same effect was 
achieved by specifying the JVM parameters in the CATALINA_OPTS variable.
"

I'm not sure this is completely fair.  Oddly equal numbers here may not 
be fair....whoa???  Meaning that I'm not sure the default Perm, tenured 
and eden generation are sized the same between windows and Linux.  This 
may mean that you have "effectively" less memory on one than the other 
or different on one rather than the other.  Again the GC log could help 
us see what happened here.  I'm also curious what would happen if you up 
the ratio for full collections (assuming they are occuring).

-Andy