Tech Insider					     Technology and Trends


			      USENET Archives

From: m...@ms.com
Subject: Disturbing information - Linux vs NT - true or false? - 
Educated comments please!
Date: 1999/04/15
Message-ID: <37195f90.561277394@news.magmacom.com>
X-Deja-AN: 466601397
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=ISO-8859-1
Organization: ms
MIME-Version: 1.0
NNTP-Posting-Date: Thu, 15 Apr 1999 01:39:37 EDT
Newsgroups: alt.os.linux,alt.linux.sux,alt.uu.comp.os.linux,aus.computers.linux,
comp.os.linux.advocacy

Please check out the following link comparing Linux (w/Apache) to NT:

http://www.mindcraft.com/whitepapers/nts4rhlinux.html

Just in case this link disappears before some of you see it, I'll copy
the text portion below and attach a PDF copy in the next msg.  Since,
I'm new to Linux, I cannot determine whether or not this is fact or
fiction.

Please, comment with qualified remarks.

************************************************************************
text (see web site, if available for graphics)

Web and File Server Comparison:
Microsoft Windows NT Server 4.0 and Red Hat Linux 5.2 Upgraded to the
Linux 2.2.2 Kernel
April 13, 1999

Microsoft Windows NT Server 4.0 is 2.5 times faster than Linux as a
File Server and 3.7 times faster as a Web Server 
Mindcraft tested the file-server and Web-server performance of
Microsoft Windows NT Server 4.0 and Red Hat Linux 5.2 upgraded to the
Linux 2.2.2 kernel (in this report referred to simply as Linux) on a
Dell PowerEdge 6300/400 server. For Linux, we used Samba 2.0.3 as the
SMB file server and Apache 1.3.4 as the Web server. For Windows NT
Server we used its embedded SMB file server and Internet Information
Server 4.0 Web server.

Figure 1 summarizes the file server peak throughput measured for each
system in megabits per second (Mbits/Sec). It also shows how many test
systems were needed to reach peak performance. The results show that,
as a file-server, Windows NT Server 4.0 is 2.5 times faster than Linux
with Samba. In addition, Windows NT Server reaches its peak
performance at 2.3 times the number of test systems that Linux with
Samba does. 

Figure 1: File Server Peak Performance
(larger numbers are better for all metrics)

Figure 2 shows the Web server peak performance measured in HTTP GET
requests per second and throughput measured in megabytes per second
(MB/Sec). The Web server results show that Windows NT Server 4.0 is
over 3.7 times faster than Linux with Apache. As discussed in the Web
Server Performance section below, the performance of Linux with Apache
drops to 7% of the peak level when we increased the number of test
threads above 160. Thus, Linux/Apache performance becomes unreliable
under heavy load. Windows NT Server, on the other hand, continues to
increase its performance up through 288 test threads. We believe that
we did not reach the true peak performance of the system under Windows
NT Server 4.0 because we did not have more test systems available.

Figure 2: Web Server Peak Performance
(larger numbers are better for all metrics)



Mindcraft tested file server performance using the Ziff-Davis
Benchmark Operation NetBench 5.01 benchmark. We used the Ziff-Davis
Benchmark Operation WebBench 2.0 benchmark to test Web server
performance. We tuned each operating system, file server, and Web
server according to available documentation and tuning parameters
available in published benchmarks. The Products Tested section gives
the detailed operating system tuning we used. 

Although much has been written about the performance and stability of
Linux, Samba, and Apache, our tests show that Windows NT Server 4.0
performs significantly faster and handles a much larger load on
enterprise class servers.

Performance Analysis
Looking at NetBench Results
The NetBench 5.01 benchmark measures file server performance. Its
primary performance metric is throughput in bytes per second. The
NetBench documentation defines throughput as "The number of bytes a
client transferred to and from the server each second. NetBench
measures throughput by dividing the number of bytes moved by the
amount of time it took to move them. NetBench reports throughput as
bytes per second." We report throughput in megabits per second to make
the charts easier to compare to other published NetBench results.

We tested file-sharing performance on Windows NT Server 4.0 and Linux
on the same system. We used Samba 2.0.3 to provide SMB file sharing
for Linux. Figure 3 shows the throughput we measured plotted against
the number of test systems that participated in each data point.

Figure 3: NetBench Throughput Performance (larger numbers are better) 



Understanding how NetBench 5.01 works will help explain the meaning of
the NetBench throughput measurement. NetBench stresses a file server
by using a number of test systems to read and write files on a server.
A NetBench test suite is made up of a number of mixes. A mix is a
particular configuration of NetBench parameters, including the number
of test systems used to load the server. Typically, each mix increases
the load on a server by increasing the number of test systems involved
while keeping the rest of the parameters the same. We modified the
standard NetBench NBDM_60.TST test suite to increase the number of
test systems to 144 and the increment in test systems for each mix to
16 in order to test each product to its maximum performance level. The
NetBench Test Suite Configuration Parameters show you exactly how we
configured the test.

NetBench does a good job of testing a file server under heavy load. To
do this, each NetBench test system (called a client in the NetBench
documentation) executes a script that specifies a file access pattern.
As the number of test systems is increased, the load on a server is
increased. You need to be careful, however, not to correlate the
number of NetBench test systems participating in a test mix with the
number of simultaneous users that a file server can support. This is
because each NetBench test system represents more of a load than a
single user would generate. NetBench was designed to behave this way
in order to do benchmarking with as few test systems as possible while
still generating large enough loads on a server to saturate it.

When comparing NetBench results, be sure to look at the configurations
of the test systems because they have a significant effect on the
measurements that NetBench makes. For example, the test system
operating system may cache some or all of the workspace in its own RAM
causing the NetBench test program not to go over the network to the
file server as frequently as expected. This can significantly increase
the reported throughput. In some cases, we’ve seen reported results
that are 75% above the available network bandwidth. If the same test
systems and network components are used to test multiple servers with
the same test suite configuration, you can make a fair comparison of
the servers.

File Server Performance Analysis
With this background, let us analyze what the results in Figure 3 mean
(the supporting details for this chart are in NetBench Configuration
and Results).  The three major areas to look at are: 

Peak Performance 
This tells you the maximum throughput you can expect from a file
server. NetBench throughput is primarily a function of how quickly a
file server responds to file operations from a given number of test
systems. So a more responsive file server will be able to handle more
operations per second, which will yield higher throughput.

Shape of the Performance Curve 
How a product performs as a function of load is perhaps the most
meaningful information NetBench produces. If performance drops off
rapidly after the peak, users may experience significant unpredictable
and slow response times as the load on the server increases. On the
other hand, a product whose performance is flat or degrades slowly
after the peak can deliver more predictable performance under load. 

Where Peak Performance Occurs 
How quickly these products reach their peak performance depends on the
server hardware performance, the operating system performance, and the
test system performance. In this case, we tested a fast server
platform with significantly slower clients. This test lab setup meant
that small numbers of clients could not generate enough requests to
utilize the server processors fully. So the part of the throughput
performance curve to the left of the peak does not tell us anything of
interest. The performance curve after the peak shows how a server
behaves as it is overloaded. 

File Server Performance Conclusions 
Windows NT Server 4.0 is a high-performance file server that helps
users be more productive than a Linux/Samba file server would. We base
this conclusion on the following analysis: 

The peak performance for Windows NT Server 4.0 was 286.7 Mbits/second
at 112 test systems while Linux/Samba reached a peak of 114.6
Mbits/second at 48 test systems. Thus, Windows NT Server reached a
peak performance level that was 2.5 times that of Linux/Samba. The
test results also show that Windows NT Server 4.0 is 43.5% faster than
Linux/Samba at 48 test systems. Only on a lightly loaded server, with
1 or 16 test systems, does Linux/Samba outperform Windows NT Server
and then by only 26%.

The shapes of the performance curves for both Windows NT Server 4.0
and Linux/Samba indicate that we reached peak performance and went
beyond it. Performance for both Windows NT Server 4.0 and Linux/Samba
degrades slowly as the load is increased past the peak performance
load. So both systems should deliver predictable performance even
under overload conditions.

The peak performance for Windows NT Server 4.0 occurs at 112 test
systems while that for Linux/Samba occurs at 48 test systems. This
means that the Windows NT Server 4.0 can handle over 2.3 times the
load of Linux/Samba while delivering significantly better performance.


Looking at WebBench Results
In order to understand what the WebBench measurements mean you need to
know how WebBench 2.0 works. It stresses a Web server by using a
number of test systems (called clients in the WebBench documentation)
to request URLs. Each WebBench test system can be configured to use
multiple worker threads (threads for short) to make simultaneous Web
server requests. By using multiple threads per test system, it is
possible to generate a large enough load on a Web server to stress it
to its limit with a reasonable number of test systems. The other
factor that will determine how many test systems and how many threads
per test system are needed to saturate a server is the performance of
each test system. 

The number of threads needed to obtain the peak server performance
depends on the speed of the test systems and the server. Because of
this, it is not meaningful to compare performance curves generated
using different test beds. However, it is meaningful to compare the
peak server performance measurements from different test beds, as long
as the true peak has been reached, because each server sees enough
requests from WebBench test systems to make it reach its maximum
performance level. In addition, it is meaningful to compare
performance curves for different servers based on the number of
threads, not systems, at each data point only if the same test bed is
used. That is why our graphs below show the number of test threads for
each data point.

WebBench can generate a heavy load on a Web server. To do this in a
way that makes benchmarking economical, each WebBench thread sends an
HTTP request to the Web server being tested and waits for the reply.
When it comes, the thread immediately makes a new HTTP request. This
way of generating requests means that a few test systems can simulate
the load of hundreds of users. You need to be careful, however, not to
correlate the number of WebBench test systems or threads with the
number of simultaneous users that a Web server can support since
WebBench does not behave the way users do.

Web-Server Performance Analysis
WebBench 2.0 gives two metrics for comparing Web server performance: 

The number of HTTP GET requests per second. 
The number of bytes per second that a Web server sends to all test
systems. 
We tested both Web servers using the standard WebBench
zd_static_v20.tst test suite, modified to increase the number of test
systems to 144 and the increment in test systems for each mix to 16 in
order to test each product to its maximum performance level. This
standard WebBench test suite uses the HTTP 1.0 protocol without
keepalives. 

Figure 4 shows the total number of requests per second for both
Windows NT Server 4.0/IIS 4 and Linux/Apache 1.3.4. The x-axis shows
the total number of test threads used at each data point; a higher
number of threads indicate a larger load on the server. Figure 5 gives
the corresponding throughput for each platform.

Figure 4: HTTP Requests/Second Performance (larger numbers are better)




With this background, let us analyze what the results in Figure 4 and
Figure 5 mean (the supporting detail data for these charts are in the
WebBench Configuration and Results section). As with NetBench, the
three major areas to look at are:

Peak Performance

This tells you the maximum requests per second that a Web server can
handle and the peak throughput it can generate. A more responsive Web
server will be able to handle more requests per second, which will
yield higher throughput. 

Shape of the Performance Curve

The shape of the performance curve shows how a Web server performs as
a function of load. If performance drops off rapidly after the peak,
users may experience significant unpredictable and slow response times
as the load on the Web server increases. On the other hand, a Web
server that degrades performance slowly after the peak will deliver
more predictable performance under load. 

Where Peak Performance Occurs

How quickly a Web server reaches its peak performance depends on the
performance of the server hardware, the operating system, the Web
server software, and the test systems. For this report, we tested a
fast server system with significantly slower clients. This test bed
setup meant that small numbers of clients could not generate enough
requests to utilize the server processors fully. So the part of the
performance curves to the left of the peak does not tell us anything
of interest. The performance curves after the peak show how a server
behaves as it is overloaded. 

Figure 5: Web Server Throughput Performance (larger numbers are
better)



Web-Server Performance Conclusions
Windows NT Server 4.0/IIS 4 significantly out-performs Linux/Apache
1.3.4 and provides much more predictable and robust performance under
heavy load. On a given large workgroup or enterprise-class computer,
Windows NT Server/IIS will satisfy a much larger Web server workload
than Linux/Apache will. We base these conclusions on the following
analysis:

The peak performance for Windows NT Server 4.0/IIS 4 was 3,771
requests per second at 288 threads while Linux/Apache 1.3.4 reached a
peak of 1,000 requests per second at 160 threads. Thus, Windows NT
Server/IIS reached a peak performance level that was almost 3.8 times
that of Linux/Apache. Based on the increasing performance for Windows
NT Server/IIS from 256 to 288 threads, we believe that peak
performance would have increased if we had more test systems available
to us. 

The shapes of the requests per second and throughput performance
curves for Windows NT Server 4.0/IIS 4 indicate that we probably did
not reach the maximum performance levels possible with the Dell
PowerEdge 6300 system. On the other hand, the performance curves for
Linux/Apache indicate that we did reach peak performance and went
beyond it. These results show very serious performance degradation
from 1,000 requests per second at 160 threads to 68 requests per
second at 224 threads. Please see our comments in the next section,
Observations, for more information about this. 

The peak performance we measured for Windows NT Server/IIS occurred at
288 threads while that for Linux/Apache occurred at 160 threads. This
means that the Windows NT Server/IIS can handle over 1.8 times the
load of Linux/Apache. In addition, the test results show that Windows
NT Server/IIS is 140% faster than Linux/Apache at 160 threads, the
peak for Linux/Apache. 

Observations
The comments in this section are based on observations we made during
the testing.

Linux Observations
The Linux 2.2.x kernel is not well supported and is still changing
rapidly. The following observations led us to this conclusion: 
We started the tests using Red Hat Linux 5.2 but had to upgrade it to
the Linux 2.2.2 kernel because its Linux 2.0.36 kernel does not
support hardware RAID controllers and SMP at the same time. In
addition, there are comments in the Red Hat Linux 5.2 source code
noting that the SMP code is effectively Beta-level code and should not
be used at the same time as the RAID driver. For this reason, we
upgraded to the Linux 2.2.2 kernel, which has full support for both
hardware RAID controllers and SMP to be used simultaneously. As of the
date this report was written, Red Hat did not ship or support a
product based on the Linux 2.2.x kernel. 
The instructions on how to update Red Hat Linux 5.2 to the Linux 2.2.x
kernel at the Red Hat Web site were complete but require care from the
user. It is quite possible to put the system in a state where you must
reload all software from scratch since you need to recompile and
reinstall the kernel. 
We contacted Red Hat for technical support after we saw that Linux was
getting such poor performance. They told us that they only provided
installation support and that they did not provide any support for the
Linux 2.2.2 kernel. 
We posted notices on various Linux and Apache newsgroups and received
no relevant responses. Also, we searched the various Linux and Apache
knowledge bases on the Web and found nothing that we could use to
improve the performance we were observing. 
Linux kernels are available over the Internet from www.kernel.org and
its mirror sites. The issue is that there are many updates to the
kernel. For example, as of the time of writing this report, we found
the following kernel update history: 

Linux Kernel Version
 Release Date
Linux 2.2.0  January 25, 1999
Linux 2.2.1  January 28, 1999
Linux 2.2.2  February 22, 1999
Linux 2.2.3  March 8, 1999
Linux 2.2.4  March 23, 1999
Linux 2.2.5  March 28, 1999

Linux performance tuning tips and tricks must be learned from
documentation on the Net, newsgroups, and trial-and-error. Some tunes
require you to recompile the kernel. We came to this conclusion from
the following observations: 
The documentation on how to configure the latest Linux kernel for the
best performance is very difficult to find. 
We were unable to obtain help from various Linux community newsgroups
and from Red Hat. 
We were unable to find any books or web sites that addressed
performance tuning in a clear and concise manner. At best we found
bits and pieces of information from dozens of sites. 
The kernel source code contains comments regarding tuning and
configuration. 
Samba Observations
Samba was easy to set up for file sharing once you spent a day or two
learning how it fits with Linux. For people not familiar with
UNIX/Linux systems, it may take longer to do the installation. 
The documentation available with Samba and in books is clear and easy
to follow. 
Apache Observations
Apache’s performance on Red Hat Linux 5.2 upgraded to the Linux 2.2.2
kernel is unstable under heavy load. We came to this conclusion from
the following observation: 
Performance collapses with a WebBench load above 160 threads. We
verified that the problem was with Apache, not Linux, by restarting
Apache at the 256 threads data point during a WebBench test run. After
the restart, Apache performance climbed back to within 30% of its peak
from a low of about 6% of the peak performance. 
We tried many configurations suggested in Apache books and in comments
in the Apache high performance configuration file. 
There were no error messages in the Web server error log or operating
system logs to indicate why Apache performance collapsed. 
Products Tested
Configuration and Tuning
We used the same Dell PowerEdge 6300/400 to test both Windows NT
Server 4.0 and Red Hat Linux 5.2 upgraded to the Linux 2.2.2 kernel.
Table 1 shows the system configuration we used.

Table 1: Dell PowerEdge 6300/400 Configuration

Feature
 Configuration
 
CPU 4 x 400 MHz Pentium II Xeon 
Cache: L1: 16 KBI + 16 KB D; L2:1 MB 
RAM 4 GB 100 MHz SDRAM ECC 
Disk PowerEdge RAID II Adapter, 32 MB cache, RAID 0, BIOS v1.47,
stripe size = 64 KB, wirte policy = writeback, read policy = adaptive,
cache policy = directIO, raid across two channels, with two logical
drives:

Drive C/OS: 1 x 9 GB Seagate Cheetah, Model ST39102LC, 10,000 RPM; two
partitions – one for each OS 

Drive D/Data: 8 x 4 GB Seagate Barracuda, Model ST34573WC, 7,200 RPM;
two partitions – one data partition for each OS 
 
Networks 4 x Intel EtherExpress Pro 100B Network Interface Cards 

Windows NT Server 4.0 Configuration
Windows NT Server 4.0 Enterprise Edition with Service Pack 4 installed

Used 1024 MB of RAM (set maxmem=1024 in boot.ini) 
Server set to maximize throughput for file sharing 
Foreground application boost set to NONE 
Set registry entries:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services: 
\NDIS\Parameters\ProcessorAffinityMask=0 
Tcpip\Parameters\Tcpwindowsize = 65535 
Used the NIC control panel to set the following for all four NICs: 
Receive Buffers = 200 (default is 32; this setting is under “Advanced
Settings”) 
NIC speed = 100 Mbit (default is “auto”) 
Spooler service was disabled 
Page file size set to 1012 MB on the same drive as the OS 
The RAID file systems were formatted with 16 KB allocation unit size
(the /a option of the format command) and an NTFS file system 
Increased the file system log on the RAID file system to 65536 K using
the chkdsk f: /l:65536 command 
Used the affinity tool to bind one NIC to each CPU
(ftp://ftp.microsoft.com/bussys/winnt/winnt-public/tools/affinity/) 
Rebuilt the NetBench file system between each run 
Internet Information Server 4 (IIS 4) Configuration
Used the NIC control panel to set the following for all four NICs: 
Coalesce Buffers = 32 (default is 8) 
Receive Buffers = 1023 
Transmit Control Blocks = 80 (default is 16) 
Adaptive Transmit Threshold = on (default is on) 
Adaptive Technology = on (default is on) 
Adaptive Inter-Frame Spacing = 1 (default is 1)  
Map Registers = 64 (default is 64)  
SMTP, FTP, MSDTC, and Browser services were disabled 
Set registry entries:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services: 
\InetInfo\Parameters\ListenBackLog=200 
\InetInfo\Parameters\ObjectCacheTTL=0xFFFFFFFF 
\InetInfo\Parameters\OpenFileInCache=0x5000 
Using the IIS Manager 
Set Logging – “Next Log Time Period” = “When file size reaches 100 MB”

Set performance to “More than 100,000” ? Removed all ISAPI filters 
Removed all Home directory application mappings except .asp 
Removed permissions for “Application Settings” 
Logs on the F: drive (RAID) along with the WebBench data files 
Server set to maximize throughput for applications when doing WebBench
tests 
Linux Configuration
Followed the Red Hat instructions for upgrading Red Hat Linux 5.2 to
the Linux 2.2.x kernel
(http://www.redhat.com/support/docs/rhl/kernel-2.2/kernel2.2-upgrade.html)

Used the AMI 0.92 version of the MegaRAID driver for Linux (this was
the latest driver available from the AMI Web site) 
Compiled the Linux 2.2.2 kernel using gcc version 2.7.2.3 
Kernel automounter support = no (was yes) 
NFS file system support = yes 
Enabled SMP support 
The following processes were running immediately before the NetBench
and WebBench tests: init, (kflushd), (kpiod), (kswapd), /sbin/kerneld,
syslogd, klogd, crond, inetd, bash, /sbin/mingetty [on tty2, tty3,
tty4, tty5, and tty6], update (bdflush), and portmap 
The Linux kernel limited itself to use only 960 MB of RAM 
Samba 2.0.1 Configuration
Set HAVE_SHARED_MMAP = 1, HAVE_MMAP = 1, and 
CFLAGS = -O before compiling 
Compiled Samba using gcc version 2.7.2.3 and glibc 2.0.7 
Changes in /usr/local/samba/lib/smb.conf: 
wide links = no 
getwd cache = yes  
read prediction = yes 
status = no 
raw read = yes 
raw write = yes 
Rebuilt file system on the RAID between NetBench runs using the
command mke2fs –b 4096 /dev/sdb1. Note that mke2fs does not support
file systems with block sizes above 4096 bytes. 
Apache 1.3.4 Configuration
Set OPTIM = “-04 –m486” before compiling 
Set EXTRA_CFLAGS=-DHARD_SERVER_LIMIT=500 
Compiled Apache using gcc version 2.7.2.3 and glibc 2.0.7 
Disabled the following modules: 
mod_env 
mod_setenvif 
mod_negotiation 
mod_alias 
mod_userdir 
mod_autoindex 
mod_access 
mod_auth 
mod_include 
mod_cgi 
mod_actions 
mod_status 
mod_imap 
The following parameters were set in the Apache config.h file: 
MinSpareServers 1 
MaxSpareServers 290 
StartServers 10 
MaxClients 290 
MaxRequestsPerChild 10000 
.htaccess file access was disabled 
LogFormat "%h %l %u %t \"%r\" %>s %b" common 
KeepAlive Off 
Test Lab
The Test Systems and Network Configuration
Mindcraft ran these tests using a total of 144 test systems made up of
two types. Table 2 and Table 3 show the system configurations. We used
72 Type A systems and 72 Type B systems.

Table 2: Type A Test Systems Configuration

Feature
 Configuration
 
CPU 133 MHz Pentium. All are identical Mitac systems. 
RAM 64 MB 
Disk 1 GB IDE; standard Windows 95 driver 
Network All systems used Intel E100B LAN Adapter (100Base-TX) using
e100b.sys driver version 2.02 
Network software: Windows 95 TCP/IP driver. 
 
Operating System Windows 95, version 4.00.950 

Table 3: Type B Test Systems Configuration

Feature
 Configuration
 
CPU 133 MHz Pentium. All are identical Mitac systems. 
RAM 64 MB 
Disk 1 GB IDE; standard Windows 98 driver 
Network All systems used Intel E100B LAN Adapter (100Base-TX) using
e100b.sys driver version 2.02 
Network software: Windows 98 TCP/IP driver.
 
Operating System Windows 98 

Two switched networks made up of 12 Bay Networks LS28115 switches
connected the test systems to the Dell PowerEdge 6300. Figure 6 shows
the test lab configuration.

Figure 6: Test Lab Configuration



Mindcraft Certification
Mindcraft, Inc. conducted the performance tests described in this
report between March 10 and March 13, 1999. Microsoft Corporation
sponsored the testing reported herein. 

Mindcraft certifies that the results reported accurately represent the
file-server performance of Microsoft Windows NT Server 4.0 and Red Hat
Linux 5.2 upgraded to the Linux 2.2.2 kernel with Samba 2.0.1 running
on a Dell PowerEdge 6300/400 as measured by NetBench 5.01. Also, we
certify that the Web-server performance reported for Windows NT Server
4.0 with IIS 4 and for Red Hat Linux 5.2 upgraded to the Linux 2.2.2
kernel with Apache 1.3.4 accurately represent the WebBench 2.0
measurements we made on a Dell PowerEdge 6300/400. 

Our test results should be reproducible by others using the same test
lab configuration, the same Dell computer, and the software
configurations and modifications documented in this report. 

NetBench Configuration and Results
Items in blue were modified from the standard WebBench 2.0 NBDM_60.TST
test.

NetBench Test Suite Configuration Parameters
Parameter Value
 Comment
 
Ramp Up 30 seconds This is the amount of time at the beginning of a
test mix during which NetBench ignores any file operations that occur.

Ramp Down 30 seconds This is the amount of time at the end of a test
mix during which NetBench ignores any file operations that occur. 
Length 660 seconds The total time for which NetBench will run a test.
It includes both the Ramp Up and Ramp Down times. 
Delay 5 seconds How long a test system is to wait before starting a
test after it is told by the controller to start. Each test system
will pick a random number less than or equal to this value to stagger
the start times of all test systems. 
Think Time 2 seconds How long each test system will wait before
performing the next piece of work. 
Workspace 20 MB The size of the data files used by a test system, each
of which has its own workspace. 
Save Workspace Yes The last mix has this parameter set to No to clean
up after the test is over. 
Number of Mixes 10 Each mix tests the server with a different number
of test systems. Mix 1 uses 1 system, Mix 2 uses 16 systems, and
subsequent mixes increment the number of test systems by 16.  
Number of Clients 144 The maximum number of test systems available to
be used by any test mix. The actual number of test systems that
participate in a mix depends on the number specified in the mix
definition and whether an error occurred to take a test system out of
a particular mix.  


WebBench Test Suite Configuration Parameters
Parameter Value
 Comment
 
Ramp Up 30 seconds This is the amount of time at the beginning of a
test mix during which WebBench ignores any file operations that occur.

Ramp Down 30 seconds This is the amount of time at the end of a test
mix during which WebBench ignores any file operations that occur. 
Length 300 seconds The total time for which WebBench will run a test.
It includes both the Ramp Up and Ramp Down times. 
Delay 0 seconds How long a test system is to wait before starting a
test after it is told by the controller to start. Each test system
will pick a random number less than or equal to this value to stagger
the start times of all test systems. 
Think Time 0 seconds How long each test system will wait before
performing the next piece of work. 
Number of Threads 2  The number of worker threads used on each test
system to make requests to a Web server. The total number of threads
in a mix is the number of threads times the number of clients in that
mix.  
Receive Buffer 4096 bytes The size of the buffer WebBench uses to
receive data sent from a Web server. 
% HTTP 1.0 Requests 100 % The percentage of HTTP requests that are
made according to the HTTP 1.0 protocol. WebBench does not support
keepalives for HTTP 1.0. 
Number of Mixes 10 Each mix tests the server with a different number
of test systems. Mix 1 uses 1 system, Mix 2 uses 16 systems, and
subsequent mixes increment the number of test systems by 16.  
Number of Clients 144 The maximum number of test systems available to
be used by any test mix. The actual number of test systems that
participate in a mix depends on the number specified in the mix
definition and whether an error occurred to take a test system out of
a particular mix.  


NOTICE: 

The information in this publication is subject to change without
notice. 

MINDCRAFT, INC. SHALL NOT BE LIABLE FOR ERRORS OR OMISSIONS CONTAINED
HEREIN, NOR FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES RESULTING FROM THE
FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL. 

This publication does not constitute an endorsement of the product or
products that were tested. This test is not a determination of product
quality or correctness, nor does it ensure compliance with any
federal, state or local requirements. 

The Mindcraft tests discussed herein were performed without
independent verification by Ziff-Davis and Ziff-Davis makes no
representations or warranties as to the results of the tests.

Mindcraft is a registered trademark of Mindcraft, Inc. 

Product and corporate names mentioned herein are trademarks and/or
registered trademarks of their respective companies.

			      USENET Archives


The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or 
research.


Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/