Read an Excerpt

Chapter 13
Fast as Fast Can Be (or, The Jackalope's Guide to Network Performance)

In This Chapter

• Understanding network bottlenecks
• Tuning your network
• Making your network server faster
• Making your network clients faster

---

It really is true that there's no such thing as a free lunch. When you network your computers, you reap the benefits of being able to share information and resources such as disk drives and printers. But there are also many costs. There is the cost of purchasing network cards, cable, and software, plus the cost of the time required to install the network, learn how to use it, and keep
it running.

There's another cost of networking you may not have considered yet: the performance cost. No matter how hard you try, you can't hide the ugly truth that putting a computer on a network slows it down. It takes a bit longer to retrieve a word processing document from a network disk than it does to retrieve the same document from your local disk drive. Sorting that big database file takes a bit longer. And printing a 300-page report also takes a bit longer.

Notice that I've used the word "bit" three times now. Lest my editor chide me for Overuse of a Three-Letter Word, I'd better point out that I used the word three times to make a point. The network inevitably slows things down, but only a bit. If your network has slowed things down to a snail's pace-so that your users are routinely taking coffee breaks whenever they save a file- you've got a performance problem you can probably solve.

What Exactly Is a Bottleneck?

The term bottleneck does not in any way refer to the physique of your typical computer geek. (Well, I guess it could, in some cases.) It is, rather, a phrase coined by computer geeks when they discovered that the tapered shape of a bottle of Jolt Cola limited the rate at which they could consume the beverage. "Hey," a computer geek said one day, "the narrowness of this bottleneck limits the rate at which I can consume the tasty caffeine-laden beverage contained within. This draws to mind an obvious analogy to the limiting effect that a single slow component of a computer system can have upon the performance of the system as a whole."

"Fascinating," replied all the other computer geeks who were fortunate enough to be present at that historic moment.

The phrase stuck and is used to this day to draw attention to the simple fact that a computer system is only as fast as its slowest component. It's the computer equivalent of the old truism that a chain is only as strong as its weakest link.

For a simple demonstration of this concept, consider what happens when you print a word processing document on a slow dot-matrix printer. Your word processing program reads the data from disk and sends it to the printer. Then you sit and wait while the printer prints the document.

Would buying a faster CPU or adding more memory make the document print faster? No. The CPU is already much faster than the printer, and your computer already has more than enough memory to print the document. The printer itself is the bottleneck, so the only way to print the document faster is to replace the slow printer with a faster one.

• A computer system always has a bottleneck. Buying a faster printer makes the bottleneck less severe, but the printer will still be a bottleneck. In some extreme cases, a printer can process information faster than the computer can send it. In this case, the printer is not the bottleneck; the parallel port the printer is attached to has become the bottleneck. There is still a bottleneck, but it's been moved around. Since you can't eliminate bottlenecks, the best you can do is limit their effect.

• One way to limit the effect of abottleneck is to avoid waiting for the bottleneck. For example, you can use WordPerfect's print spooling feature to avoid waiting for the printer. This doesn't speed up the printer, but it does free you up to do other work while the printer chugs along. Network print spooling works the same way.

• One of the reasons computer geeks are switching from Jolt Cola to Snapple is that Snapple bottles have wider necks.

What Are the Ten Most Common
Network Bottlenecks?

Funny you should ask. Here they are, in no particular order:

1. The CPU in the file server. If the file server will be used extensively, it should have a powerful CPU - Pentium is best. This is especially true if you're using NetWare.

2. The amount of memory in the file server. You can set up the file server to take advantage of lots of extended memory. A few extra megabytes of server memory can almost always be put to good use.

3. The file server computer's bus. Oops . . . this is kind of technical, so I'll put the details in a sidebar you can skip. The nontechnical version is this: Buy a server computer that has a high-speed local bus if you can afford it.

4. The network card. Use 16-bit network cards; cheaper 8-bit cards slow things down. Better yet, use EISA or PCI bus cards.

5. The file server's disk drive. If possible, use EIDE or SCSI drives. Sorry! I went technical on you again. Time for another sidebar.

6. The file server's disk controller card. All disks must be connected to the computer via a controller card, and sometimes the bottleneck isn't the disk itself, but the controller card. A beefed-up controller card can do wonders for performance.

7. The configuration options setup for the server. Even simple peer-to-peer networks have all sorts of options you can configure. Some of these options can make the difference between a pokey network and a zippy network. Unfortunately, there aren't any hard-and-fast rules for setting these options. Otherwise, there wouldn't be options.

8. Windows! If you use a peer-to-peer network, don't run Windows on the server. You'll just bog things down. (Of course, you can't avoid running Windows on the server computer if you use Windows for Workgroups, Windows 95, or Windows NT Server.)

9. DOS! No matter how hard they try, DOS-based networks will never be as fast as NetWare or Windows NT networks. NetWare and Windows NT have an advantage because they are written specifically to take advantage of the fast features of 386, 486, and Pentium processors. DOS is not.

10. The network itself. If you have too many users, the network can become bogged down. The solution is to divide the network into two smaller networks connected with a cool little black box called a bridge.

The hardest part about improving the performance of a network is determining what the bottlenecks are. With sophisticated test equipment and years of experience, network gurus can make pretty good educated guesses. Without the equipment and experience, you can still make pretty good uneducated guesses.

The Compulsive Way to Tune Your Network

There are two ways to tune your network. The first is to think about it a bit, take a guess at what may improve performance, try it, and see whether the network seems to run faster. This is the way most people go about it.

Then there's the compulsive way, suitable for people who organize their sock drawers by color and their food cupboards alphabetically by food groups, or worse, alphabetically within food groups. The compulsive approach to tuning a network goes something like this:

1. Establish a method for objectively testing the performance of some aspect of the network.

This is called abenchmark. For example, if you want to improve the performance of network printing, use a stopwatch to time how long it takes to print a fairly large document.

2. Now, change one variable of your network configuration and rerun the test.

For example, if you think increasing the size of the disk cache will improve performance, change the cache size, restart the server, and run the benchmark test. Note whether the performance improved, stayed the same, or became worse.

3. Repeat Step 2 for each variable you want to test.

If possible, test each variable separately-in other words, reverse the changes you've made to other network variables before proceeding.

• Write down the results of each test so that you'll have an accurate record of the impact each change has on your network's performance.

• It's important that you change only one aspect of the network each time you run the benchmark. If you make several changes, you won't know which one resulted in the change. Or it could be that one change improved performance, but the other change worsened performance so that the changes canceled each other out - kind of like offsetting penalties in a football game.

• Make sure that no one else is using the network when you conduct the test; otherwise, the unpredictable activities of other network users will spoil the test.

• To establish your baseline performance, run your benchmark test two or three times to make sure that the results are repeatable. If the print job takes one minute the first time, three minutes the second time, and 22 seconds the third time, there's something wrong with the test. A variation of just a few seconds is acceptable, though.

• Standardized benchmark tests are available from on-line services such as CompuServe. These tests aren't as good as tests you devise yourself because the tests you come up with are likely to reflect the type of work you do on your network. Nevertheless, they are useful if you can't come up with any realistic tests on your own.

Tuning a Peer-to-Peer Server

When you use a peer-to-peer network such as LANtastic, there are lots of options you can fiddle around with to improve the performance of your server computers. The time spent is worthwhile to a point because the effect of a more efficient server computer is noticed by all users of the network.

When you first install your network, make no attempt to tune the server for efficient performance. In fact, do what you can to make sure that the server runs as inefficiently as possible. Then, after the network has been running a week or two, announce that you're sick and tired of lackluster network performance and you're not going to take it any more. Apply the basic performance-tuning techniques described here and you'll be a hero.

Using a disk cache

The numero uno thing you can do to boost the performance of a server is to use a program called a disk cache. A disk cache dramatically improves the performance of your disk drives. Here's how it works. (This is a bit complicated, so make sure that you're sitting down before you continue.)

It's a given that computer memory (that is, RAM) can be accessed faster than disk storage, right? A disk cache works by setting aside a portion of memory to hold disk data that's frequently accessed. Whenever a network user tries to read data from the disk, the cache program checks first to see whether the data is already in the cache memory. If so, the data is read directly from memory, much faster than if it had to be accessed from the disk.

The more memory you set aside for the cache, the more likely it is that when a network user needs to retrieve data from the server's disk, the data can be retrieved quickly from cache memory instead. So the general rule is this: Set aside as much memory as humanly possible for disk cache. The cache is the reason you can never have too much memory in a network server.

• A disk-caching program isn't something you have to run out and buy. In fact, you probably already own two cache programs. Most peer-to-peer networks come with a caching program that's designed to work specifically with the network software. LANtastic comes with a caching program called LANcache. In addition, recent versions of MS-DOS also come with a disk caching program called SMARTDRV. Windows 95 has built-in caching.

• Windows NT and Netware have built-in caching.

• If you're using DOS 5.0 or an earlier version, the cache that came with your networking software is probably more sophisticated than your version of SMARTDRV. However, the DOS 6.0 and 6.2 versions of SMARTDRV are as powerful as LANcache or NLCACHE. Which one you use is a matter of preference.

• PC Tools and Norton Utilities also come with powerful disk-caching programs. If you own one of these utilities, you have even more caches to choose from.

• Computer geeks tend to have strong "opynyouns" about which cache is better. Although it's true that one cache program may achieve better scores in benchmark tests than another, the truth of the matter is that any cache is better than no cache, and the differences between caches are relatively minor. Don't fret too much over which cache to use, so long as you use one.

• A hot topic of debate among cache aficionados (called cacheoholics) is whether or not to enable the risky but speedy delayed write feature. This feature - found in LANcache, the DOS 6.0 and 6.2 versions of SMARTDRV, and Windows 95 - caches disk writes as well as disk reads. This significantly speeds up disk performance but at some risk: If a power failure, an earthquake, or the rapture occurs between the time that data is written to the cache and the time that the cache program decides to write the data to disk, there's a good chance that you'll lose data.

• If you use a DOS-based network, the command to start your disk cache should be included in the server computer's AUTOEXEC.BAT file. That way, the cache starts automatically when you turn on the server computer.

• If you use a disk-caching program, you should reduce the BUFFERS setting in your CONFIG.SYS file to 3. Find the BUFFERS line in CONFIG.SYS and change it to this:

  LANcache details to ignore

If you use LANtastic, you should add a LANCACHE command to each computer's AUTOEXEC.BAT file. Place the LANCACHE command as close to the top of AUTOEXEC.BAT file as possible, preferably right after the PATH command, like this:

path c:\dos;c:\lantasti

lancache

If you use the LANCACHE command with no parameters, it will figure out how much memory your computer has and set aside an appropriate amount to use for cache memory, up to 2MB.

If the server computer has more than 2MB of available memory, you may want to tell LANcache to create a larger cache. Then you have to add a switch to the LANCACHE command, something along these lines:

path c:\dos;c:\lantasti

lancache /cache_size=4096

Stop! You already know too much about SMARTDRV!

If you have DOS Version 6.0, 6.2 or 6.22, you have the latest and greatest version of Micro-soft's disk-caching program, affectionately known as SMARTDRV. To activate SMARTDRV, add a command to your AUTOEXEC.BAT like this one:

smartdrv

You should place the command near the top of AUTOEXEC.BAT, preferably immediately after the PATH command.

SMARTDRV checks the amount of memory your computer has to decide how much memory to use for the cache. If your computer has 4MB of memory or less, SMARTDRV uses 1MB of memory for the cache. If more than 4MB is available, SMARTDRV creates a 2MB cache.

You can change the size of the cache SMARTDRV creates by typing the size of the cache you want to use on the command line:

smartdrv 4096

This command tells SMARTDRV to create a 4MB cache. (The number you type in this command specifies the number of kilobytes you want to use for cache memory; 4MB is the same as 4096K.)

Like LANcache, SMARTDRV uses the risky delayed-write feature unless you specifically tell it not to. With DOS 6.0, you tell SMARTDRV to forget about the delayed-write feature by listing all the drives you want cached, following each drive letter with a plus sign. If you have two hard disks - C and D - you type the SMARTDRV command like this:

smartdrv c+ d+

Confusing? Yup. Microsoft saw the error of its ways and decided that DOS 6.2 would let you disable delayed-write simply by adding /X to the command:

smartdrv /x

This command tells LANcache to create a 4MB cache. (The number you type in this command specifies the number of kilobytes you want to use for cache memory; 4MB is the same as 4096K.)

LANcache uses the risky delayed-write feature unless you add the /NODELAYED_WRITES switch to the LANCACHE command, like this:

path c:\dos;c:\lantasti

lancache /cache_size=4096
/nodelayed_writes

Enabling 32-bit file access for Windows for Workgroups

If you are using Windows for Workgroups 3.11, you can improve the disk performance on your server computers by enabling a new feature called 32-bit file access, sometimes also known as VFAT (VFAT stands for Virtual File Allocation Table, but that won't be on the test). VFAT enables Windows for Workgroups to completely bypass MS-DOS when reading or writing on your disk drive. That means faster disk access.

To enable VFAT, open the Control Panel and double-click on the 386 Enhanced icon. Next, click the Virtual Memory button and then click the Change button. This brings up the dialog box shown in Figure 13-1. Click the Use 32-Bit Disk Access checkbox if it is not already checked. Then set the Cache Size control to an appropriate amount. Finally, click OK.

How much memory should you allocate for the cache? There are no hard-and-fast rules, but the following list gives some reasonable suggestions based on how much RAM the computer has:

RAM Cache size

4MB 1024KB

8MB 2048KB

12MB 3072KB

16MB 4096KB

Here are a few tidbits to ponder as you lie awake tonight:

• Microsoft claims that 32-bit file access improves disk performance by as much as 50 percent over Windows 3.1, and most benchmark tests support that claim. With 32-bit file access enabled, programs load faster, documents open faster, database queries run faster, Print Manager prints faster, and, well, you get the idea. Any Windows operation that depends on disk access runs faster when you turn on 32-bit file access.

• 32-bit file access provides its own disk caching, duplicating the function of SmartDrive. As a result, you should remove the SMARTDRV command line from your AUTOEXEC.BAT file, unless you want to use it to cache diskettes or CD-ROM drives (32-bit file access works only for hard disks).

• If you don't remove the SMARTDRV command from your AUTOEXEC.BAT file, VFAT will disable SMARTDRV but won't be able to reclaim the memory it used. So SMARTDRV becomes a real memory waster when VFAT is used.

• You can also remove the SHARE command from AUTOEXEC.BAT since
  32-bit file access duplicates its function as well.

Server start-up parameters

Most peer-to-peer networks let you play around with several variables that affect the performance of a file server. The standard settings for these options aren't always the best settings for the majority of systems, so it almost always pays to read about what options are available and make a few adjustments.

Figure 13-2 shows the settings you can change for a LANtastic server. Other networks have similar settings. I won't describe each of these configuration options here; instead, I'll zero in on the ones that are most likely to improve your network's performance if you adjust them.

Notice that the screen in Figure 13-2 is titled "Server Startup Parameters." That's because these settings are read by the network server program when you start it. You can change these settings while the network is running, but the new values you specify won't take effect until you restart the server.

Because adjusting these settings requires that you frequently restart the server, you have to ask everyone to stay off the network for a while so that you can experiment with various settings. If you're really dedicated, you may want to do this on a Saturday or in the evening.

Try adjusting the following options, as you think they are appropriate to your situation:

Maximum Users. This option says how many users can be logged in to the server at one time. The default is five; if you have more than five users on the network, you should increase this value. Increasing this value takes memory away from other functions, so you should set it to just a few more than the actual number of users you have.

Network Buffer. This option tells LANtastic how much data should be transferred from the server to the workstations each time a workstation requests disk data. The default setting for this option is 4096 (that's 4K). Most networks run better if you increase this value to 8192 (that's 8K). Try it and see. If not, you can always change it back to 4096.

If you change the server's Network Buffer setting, you also should change the /size parameter on the REDIR command found in each computer's STARTNET.BAT file. The /size value and the Network Buffer setting should be the same.

Network Tasks. This setting tells LANtastic how many network requests the server can handle simultaneously. The default is 1, which means that network requests are handled one at a time. If a user requests data from the server while the server is busy handling another user's request, the second user will just have to wait.

Your network's performance will almost surely improve if you increase this setting to 3. The benefit of additional network tasks beyond 3 is usually small.

Each task requires a separate network buffer, so if you specify 3 network tasks and an 8K network buffer, a total of 24K is set aside for the network buffers.

Printer Buffer. This option specifies the size of the buffer used for network printing. The default is a paltry 512 bytes. You almost always can improve printing performance by specifying a larger value, especially if you have a relatively fast printer. Try specifying 4096 or 8192 and see what happens.

Printer Tasks. You should set this option to the number of printers that are attached to the server. Most servers have only one printer, so the default setting of 1 is appropriate. A separate printer buffer is created for each printer task.

Run Buffer Size. This option sounds important, but it's not. It only affects the seldom-used NET RUN command, so don't worry about it.

Request Size. When a workstation requests some action from the server, the request is held in a small area of the server's memory called a request buffer until the server can process it. The default size of this request buffer is 32 bytes. Increasing this value often can improve performance, though not usually dramatically. Try increasing the request size to 512 and see what happens.

A separate request buffer is created for each network user allowed by the Maximum Users setting.

Run Burst. This setting lets you tell the server whether to place more emphasis on servicing network tasks or local tasks. The default setting of 2 means that the server will concentrate solely on network tasks for 2 "clock ticks" before checking to see whether there is any non-network processing to be done. Each clock tick is 1/18th of a second, so a run burst of 2 means that the server stops processing network tasks 9 times every second.

If a server operates as a dedicated file server, you should increase this value. I like to set it to 18 so that the server checks for local work once per second. The maximum value for this setting is 255.

LANtastic considers print despooling to be a local task. Therefore, if a server functions as both a file server and a print server, increasing the Run Burst setting improves file I/O at the expense of printer I/O. This is one of the main reasons it is best to have separate file servers and print servers if possible. To set this value appropriately for a combined file/print server, you must do what Mr. Miyagi says in the Karate Kid movies: "Find balance."

Seek Cache Size. The seek cache duplicates the function provided by the DOS FASTOPEN command: It keeps track of the locations of files on disk. The default setting is "NO CACHE," but you can change it by specifying a cache size from 1 to 64K. Most networks will benefit from FASTOPEN or a modest seek cache (16 to 32K), but there's no point in using both FASTOPEN and a seek cache.

Cached Resources. Information about each network resource (shared disk drive, printer, and so on) can be stored in cache memory to improve performance. This option sets the number of resources that are held in memory. You should set it to the number of resources defined for the server-that is, the number of shared disk drives and printers.

File Lookup Cache. Use this option only if the server has a CD-ROM drive.

Dedicating the server

LANtastic comes with a program that you can run to improve the performance of a dedicated network server. This program is called ALONE.

ALONE temporarily prevents you from running any other program at the server. The server is then free to concentrate on running the network.

• To dedicate a server, add the ALONE command as the last line of the STARTNET.BAT file. That way, ALONE automatically runs when the server is started.

• You can exit the ALONE program at any time to run programs at the server. Even if the server is not used as a client, you need to do this periodically. For example, you may need to run the NET program to manage the printer queue. You have to exit ALONE to do that.

• To exit the ALONE program, press Esc.

Tuning a Windows 95 Server

If the server tuning options for LANtastic left you with a migraine, you'll love the Windows 95 approach to tuning. The following procedure shows how to tune a Windows 95 server computer:

1. Choose SettingsÍControl Panel from the Start menu and then double-click the System icon.

The System Properties dialog box appears.

2. Click the Performance tab.

3. Click the File System button.

The dialog box shown in Figure 13-3 appears.

4. Set the drop-down list box labeled Typical role of this machine to Network Server.

Your computer is now tuned as a network server.

5. Click OK to dismiss the File System Properties dialog box.

You are returned to the System Properties dialog box.

6. Click OK to dismiss the System Properties dialog box.

That's all there is to it.

Tuning a NetWare Server

Tuning a NetWare server is both easier and more difficult than tuning a peer-to-peer server. It's easier because NetWare is an inherently more efficient network operating system. Because it doesn't run under DOS, you don't have to worry about the built-in limitations of DOS, such as the 640K limit on conventional memory. It's more difficult because NetWare provides more options you can adjust.

• NetWare has an optional mode of transmitting data over the network cable called burst mode. Burst mode can significantly improve network performance, but it's a little tricky to set up. For burst mode to work, you must install a program module on the server called PBURST.NLM and a program named BNETX.COM on each client. Burst mode doesn't work with all network cards, so you have to test it carefully before relying on it.

• Many NetWare configuration options are controlled with SET commands that you should place in the AUTOEXEC.NCF file or the STARTUP.NCF file. For example, SET lets you specify the amount of memory to use for file caching, the size of each cache buffer, the size of packet receive buffers, and a whole bunch of other stuff that's way too low-level and detailed to go into in a proud book such as this one.

• Some of the best techniques for tuning NetWare are suitable only for larger networks. For example, you can dramatically improve disk performance by using a special type of disk-drive gizmo called RAID (which stands for "Redundant Array of Inexpensive Disks"). You improve server performance by using "superservers" that have more than one CPU. And NetWare networks are often tuned by using devices such as bridges and routers to manage "traffic" on the network.

Tuning a Client

The biggest network performance benefits are gained by tuning the network servers because the effort you spend tuning one computer results in improved performance for every user who uses that server. Still, you shouldn't neglect performance tuning for the individual clients on the network.

• All clients should use some sort of local disk cache: LANcache, SMARTDRV, or some other caching program. A local disk cache can't cache network drives, but it can still improve performance when accessing non-network drives.

• Speaking of local drives, you can reduce the traffic on the network dramatically by storing frequently used data on local disks rather than on a server disk. Of course, files that have to be shared should be stored on a server drive so that the users who share the file all have access to the same copy of the file. But many files don't actually have to be shared. For example, consider placing a copy of frequently used program files on each computer rather than forcing each user to access program files from the server. This arrangement can improve network performance considerably. (Of course, you must make sure that each user has a legal copy of the software.)

• Many application programs can be customized to specify the location of temporary files. Always set these programs up so that the temporary files are stored on a local drive. Doing so is especially important for database files that are used to sort information.
  

(This passage has been abridged.)