We tested four RISC (Alpha and Mips) platforms, along with a system featuring Intel's top-of-the-line 120-MHz Pentium processor, to determine how well each functioned as an in-house Internet server. Configuring all the systems as Internet file servers lets us compare systems that do not have the same basic OS, or even comparable hardware.
This Internet-server methodology stresses the systems' CPU, disk-handling capability, and network compatibility; FPU and graphics performance is not a factor. Testing does not involve modem or serial transmission. We believe that a 28.8-Kbps phone line presents too much of a bottleneck to adequately stress these high-end systems.
TEST CONFIGURATION
We tested uniprocessor systems configured with a minimum of 64 MB of system RAM, at least 2 GB of SCSI disk storage, a single 10Base
-T Ethernet port, and a CD-ROM drive. All test units met this specification except for the Gateway P5-120XL (which had 32 MB of RAM and a 1.6-GB hard drive).
As Internet service providers, the test systems were configured with an OS capable of functioning simultaneously as an FTP, WWW (World Wide Web), and WAIS (Wide Area Information Service) server. All the systems were configured with Windows NT Server 3.5.
Our test-bed included eight Dell Dimension/P75 systems, each equipped with a 75-MHz Pentium and configured with 24 MB of RAM and Intel 10-Mb Ethernet adapters. Windows NT Workstation 3.5 was installed on each client, which, in turn, was connected to the Internet server's 10Base-T port over twisted-pair cable. Each workstation was capable of running multiple NT sessions to simulate a much larger test-bed (up to 32 simultaneous clients).
INTERNET-SERVER TESTS
Our system benchmarks are based on real-world applications and stress the processor, disk, and video compo
nents. Servers are subject to different demands, placing more emphasis on the disk and network components. The processor and memory serve mainly to cache commonly used disk pages and shuffle requests between the network and disk systems.
Different network setups and different data organizations place different load patterns on a server. For example, HTML (Hypertext Markup Language) files tend to be small, averaging around 11 KB; typical GIF-image files are larger, averaging around 14 KB. Compressed files sent via FTP are significantly larger still, averaging around 120 KB.
File access patterns also differ. The topmost pages in a WWW tree, for instance, are accessed more frequently than the lower pages, since most accesses involve a few central pages. In an FTP-based model, files can be evenly requested from any point in the directory tree. This is a reflection of the minimal amount of interdependence among files.
This means that servers that cache files and directories are affected differ
ently by WWW and FTP loads. Top-level files and directories are more likely to be cached and rerequested under a WWW load than they are under an FTP load. An FTP-oriented server can manipulate larger files and will perform better if it can read and buffer large segments from the disk.
Unlike processing with WWW and FTP, WAIS processing places a significant load on the processor. Under WAIS testing, an on-line database of information is searched for records that match a keyword-based request. The index is fairly small and is easily cacheable.
We built a mixed set of files of differing sizes based on statistics from the NCSA (National Center for Supercomputing Applications, Urbana, IL). The data from the NCSA summarizes the usage patterns at its own WWW/FTP site, including average file sizes of various types, ranges of sizes, and ratios of binary data to text data.
To create the file sources, we constructed three separate directory trees on each server. The FTP tree held over 2100 files in
21 directories (for a total of 252 MB of data), the HTTP tree had 8700 files in 121 directories (112 MB of data), and the WAIS tree included over 6195 files in 30 directories (9 MB of data). The WAIS indexes were typically about 8 MB in size.
We specified three server-load patterns, each emphasizing a different form of server use. Our FTP load represented the kind of load a server might see when it's used primarily as an FTP server with limited WWW support. This type of load is typical of a file-archiving site. The HTTP load represented a server primarily involved in HTTP servicing, which is typical of electronic publishing. And our WAIS load consisted of 50 percent HTTP requests and 50 percent WAIS requests, which is typical of a system supplying WAIS through a WWW user interface.
We varied the number of active clients (FTP tests are repeated with 16, eight, four, and two active clients; we added a test with 32 clients for the HTTP and WAIS suites), increasing the client base until the server w
as saturated and could no longer respond to the client demand. When a client could no longer open a connection to the server to request or receive data, we declared the server to be saturated.
Contributors
Siva Kumar, Technical Analyst/NSTL,
specializes in hardware and NOS (network operating system) testing.
Anthony J. Lennon, Project Manager/NSTL,
conducts reviews of systems, notebooks, and peripherals.
Stephen Platt, Ph.D., Manager of Unix Development/NSTL,
directs testing of Unix hardware and software, Windows NT, graphical systems, and NOSes.
BIX at editors@bix.com or at (603) 924-2643.
How We Tested
