Tuning networking resources

Case study: intermittently poor network performance

In this study, users report that the response time to key presses and mouse movement is occasionally very slow during the working day. They also report that resizing and moving windows is also very slow at certain times. This performance is unacceptable for the interactive applications being run -- word processing, spreadsheets, e-mail, desktop publishing, and graphics processing.

System configuration

The system's configuration is as follows:

Ethernet-based (10Base2) LAN.
10 X terminals -- used for running applications that place little processing and memory load on the main file server.
12 PC-based workstations running the SCO OpenServer Desktop System -- these run applications locally rather than on the file server.
File server -- a two Pentium 50MHz multiprocessor machine with a high specification network interface card.
Two host servers for the X terminals -- both servers are based on the 80486DX2 running at 66MHz.

From regular performance monitoring, it is known that there is no performance problem caused by X clients running on the two host servers. Users are encouraged to run applications locally if they have workstations.

Defining a performance goal

The system administrator is asked to investigate the source of the problem, and suggest means to improve the response time.

Collecting data

The system administrator runs the netstat -i command on several workstations to record networking statistics throughout the working day. A sampling interval of one minute is specified and the output is written to a file in the /tmp directory:

netstat -i 60 > /tmp/netstat_op

The administrator runs the command on several workstations to try to eliminate the possibility that faulty network interface cards are the cause of the problem.

The recorded output shows occasional short periods when the network is overloaded (for clarity, only the statistics for the network interface xxx0 are shown in this example):

       input  (xxx0)     output    
   packets errs  packets errs  colls
   ...
   110     0     101     0     0
   78      0     66      0     0
   85      1     75      2     23
   180     2     123     1     42
   120     1     55      1     18
   87      0     67      0     2
   67      0     54      0     0
   ...

At these times, the numbers of input and output errors are non-zero, and the number of collisions approaches 30% of output packets. The same behavior is observed on all the workstations on which statistics were gathered.

If the periods of heavy loading are excluded, the frequency of packet collisions approaches 0%.

Formulating a hypothesis

From the results of running netstat, the system administrator suspects that some applications must be moving large amounts of data across the network. Careful examination of the figures shows that the network is overloaded approximately 5% of the time. Periods of high loading generally last only a few minutes and seem to occur in bursts. Such behavior is typical if large files are transferred using NFS. It is unlikely to be the result of network traffic caused by remote X clients as these are run locally where possible. Possible culprits are programs used to preview PostScript and graphics image files, DTP packages, and screen-capture utilities.

Getting more specifics

With the cooperation of several users, the administrator monitors network performance using netstat over a period of 30 minutes. During this period the users run the suspect applications to load and manipulate large files across the network. The outcome of this investigation is that graphics image previewers and screen-capture utilities seem to cause the most network overhead. The files being viewed or created are often several megabytes in size.

Making adjustments to the system

There are several things that can be done to reduce the peak load on the network:

Encourage users to save and load graphics images to and from the local disk on the workstation they are using. These files may then be copied to the file server when the network is less busy.
Run screen capture and graphics preview utilities on dedicated workstations rather than on X terminals.
Splitting the network into several subnets might help if the nodes on the network can easily be divided into logically distinct groups. However, this may cause more CPU overhead on the file server if it is is used as the router between the subnets. This solution is more expensive and may make the problem worse if the wrong network topology is chosen.