Network Computingwww.networkcomputing.com

INN showed mixed results during our testing. Under high loads, INN can be slow to pick up new connections. This is due to an architectural difference in the INN code. As opposed to its multithreaded peers, it is forced to create a process to service each concurrent reader.

However, once connected, INN was the clear winner in interactive response time. In our testing, between 74 percent and 78 percent of all requests were serviced in less than 1 second. These results, however, may be determined more by the operating system than the server software itself. During load testing, we found that INN (running on Linux) appeared to cache upcoming articles better than the NT-based servers, resulting in noticeably fewer disk accesses.

We found INN to be one of the most flexible servers, with literally hundreds of options to change its behavior, but most of these must be compiled into the server. For instance, during our performance testing, the server automatically refused connections when the Unix load average exceeded 16. Since we wanted to push the server beyond its default limitations, we had to turn off this protection. At peaks during testing, the load average on the server exceeded 64. That meant going back into the master configuration (config.data) file and recompiling and installing the server.

In short, INN 1.5 is an extremely flexible server solution, however we don't recommend it to administrators who aren't familiar with compiling and configuring complex Unix software. However, since it is developed and maintained on the Interne t, it enjoys a relatively fast development cycle, and patches to include new features are posted regularly to FTP sites throughout the Internet as well as newsgroups such as www.news.admin.technical.

Netscape Communications Corp. Netscape News Server 2.01
At first look, Netscape's News Server 2.01 is hauntingly familiar to its ancestor: INN. From configuration file formats to executable names, there are seemingly more similarities than differences. However, Netscape has added not only a Web-based management server, but put a multithreaded engine under the hood. This addresses one of INN's most severe problems: the need to spawn a new reader daemon for each connected client.

On the other hand, we were surprised to find some performance problems with picking up new connections under high load. During our connection latency testing (see "Don't Keep Your Customers Waiting" on page 75 ), Netscape intermittently refused incoming connections. Also, the controlling process, or innd, appeared to lock up, cutting off communications to the Web-based administration server. Originally tested on Windows NT 3.5.1 (the recommended platform), we retested Netscape's server under Windows NT 4.0 to eliminate differences in the different versions of NT. However, the problems continued when reinstalled on NT 4.0.

Despite its performance problems, Netscape's News server is the only product in this review that supports both NT and various versions of Unix. Netscape also offers secure communications over SSL, a useful tool for implementing secure newsgroups over the Internet.

Dan Backman can be reached at dbackman@nwc.com.Jeremy Impson is a network consultant working at Syracuse University. He can be reached at jdimpson@syr.edu.

Don't Keep Your Customers Waiting
The test of any server is how long it keeps its customers waiting. In the case of Network News Transfer Protocol (NNTP) new s, clients fight for the server's time against incoming news, background processes like expiring old articles, and other users. Of course, the server should never keep a user waiting; but in the real world, few people have the luxury of a news server all to themselves. Instead of measuring the aggregate performance, or the total throughput of the server, our testing took the user's point of view: measuring how long the server took to respond to transactions (readers' requests for new articles or groups).

Likewise, since a news server is a software product, scalability is more often than not a function of hardware. The number of concurrent readers that can be serviced or the total number of articles processed per second are affected more by limitations in free memory, processor time or disk access times. For this reason, our testing kept the hardware constant, and focused on how these servers perform under very high reader loads.

News servers were tested on a Pentium 90 with 64 MB of RAM. To reduce disk and network bottlenecks, the server was outfitted with two disks (each on an independent SCSI channel) and three Ethernet interfaces. We relied on in-house-developed load-generating and latency-measuring software.

To measure each server's response time, a separate benchmarking utility simulated readers from a SPARCstation 10MP (96 MB of RAM) on a third network segment. The latency between transactions and the server's response was recorded. The performance charts at right reflect the amount of time each server kept its readers waiting. The number of seconds represents the amount of real-time each connection was left waiting for the server, while each data point represents the percentage of transactions completed in that range of time.