'; window.popUpWin.document.write(zhtm); window.popUpWin.document.close(); // Johnny Jackson 4/28/98 } //--> Windows 98 Professional Reference -- Ch 35 -- Tools and Strategies for Optimizing Windows 98

Windows 98 Professional Reference

- 35 -
Tools and Strategies for
Optimizing Windows 98

Understanding Performance Problems and Bottlenecks
- Understanding TOTE Methodology
General Performance Improvements for Windows 98
Using Windows 98 Performance Tools
Windows 98 Configuration
Recommendations
Conclusion

Solving thorny performance problems is one of the most rewarding--and sometimes frustrating--things you can do with computers. It's like solving a puzzle; sometimes you find an easy solution that makes the puzzle come together quickly, while other times it requires a lot more effort to solve. Performance problems are a lot like this. Improving the performance of a system or its applications requires patience, a keen understanding of how the system works, and a strong approach to problem solving. In this chapter, you learn how to identify and resolve performance problems under Windows 98. You'll learn about various types of performance problems, and you'll also learn about using all of the available performance-measuring and tuning features of Windows 98.

TIP: To get the most out of this chapter, start with a strong understanding of Windows 98's architecture. You should review Chapter 11, "Windows 98 Architecture and Application Support," before reading this chapter because this chapter assumes that the concepts and information in Chapter 11 are already well understood.

Understanding Performance Problems and Bottlenecks

What exactly is a performance problem? It's simple: Anytime you find that you want or need more performance from an application, you have a performance problem. Sometimes the application and system are already running as fast as they possibly can, in which case a faster computer may be required. Often, however, you can make significant improvements in performance through configuration changes to a computer or the operating system, or by upgrading a single component of the computer. Identifying the limiting factor in a performance problem is the first step to resolving it.

A bottleneck occurs when there is a single point in the system that is restricting performance, much like a four-lane highway that narrows briefly down to two lanes; all the traffic up to the bottleneck is restricted to the speed of the bottleneck area. It's sort of like the old saying: A chain is only as strong as its weakest link. You fix bottlenecks by identifying them and removing or resolving them. First, however, you have to find them, and that's one area in which a lot of knowledge, testing work, and experimentation (plus some luck!) comes into play. Performance-tuning work is often called a "black art," because being successful at it seemingly requires deals with the devil. It can truly be a tricky area to master.

Understanding TOTE Methodology

Sometimes you can resolve a performance problem quickly and easily. Perhaps it's a problem you've seen before, or perhaps the solution falls readily to hand. More often, however, you need to proceed in a stepwise fashion, carefully working through the problem. The best approach to take involves a methodology called TOTE, which stands for Test-Operate-Test-Exit. You initially test the problem to characterize it and ensure that it's repeatable and measurable. You then make a single change to the system that you think may resolve the problem (Operate). After that, you test to see if the change solved the problem. If so, you're done (Exit). If you didn't solve the problem, you loop back to the Operate step to try again, and maybe reverse the last change you made if it didn't make any difference.

For all but the simplest performance problems, it's vital that you proceed carefully. There are
a number of hazards that you need to avoid, including the following:

If you make more than one change at a time in the Operate phase, you risk not knowing what change actually solved the problem (and some of the changes may have negative long-term consequences). And if you've worsened performance, you won't know which of the changes caused the additional slowdown. It's important to change one thing at a time, and then test the results of that change--otherwise, you won't learn very much about solving the problem in the future.
You must be able to accurately and repeatedly test the condition you're trying to solve. If your testing method isn't accurate or repeatable enough, you run the risk of not knowing whether each change you make actually makes a difference, and you could lose the ability to see small improvements, thinking that they're simply random variations. It's crucial that you have an accurate and repeatable test for the Test phases.
As the old saying goes, "If you don't know where you're going, you just may get there." The problem, of course, is that you won't know where "there" is. You need to know what your Exit criteria are--when is the problem solved? This requires assessing the situation, the costs resulting from the performance problem (and balancing them against the cost of the performance troubleshooting work you do), so that you can know when to invoke the Exit phase of the TOTE methodology. Like it or not, sometimes you have to throw in the towel when it becomes unprofitable to proceed further.

It's also important to look first for non-performance-related changes that you might be able to make that could solve the problem. Not every performance problem is solved by making a computer operate faster. Sometimes you can change the procedure that a user follows so that the performance problem no longer exists, in that it's not important anymore. When assessing a situation that seems to involve a performance problem, first ask yourself if there is a non-technical way to solve the problem. There often is, and sometimes nontechnical solutions yield much larger payoffs for everyone involved, and they're sometimes much easier and less expensive to implement.

General Performance Improvements for Windows 98

At some point, a user may come to you with what appears to be a thorny performance problem, and you undertake Herculean efforts to solve it, only to discover after spending a lot of time that the problem was something very simple, like a fragmented hard disk. Don't overlook the obvious! It's usually a good idea when doing performance work to first make all of the general performance improvements you know about; these efforts might solve the problem easily and quickly. Many of these tasks are things that you can do to any system, almost falling under the category of general maintenance. These tasks, however, can often reveal or solve seemingly huge performance problems. In the following sections, all of the general performance tests and optimizations you can perform under Windows 98 are discussed, along with specific tips for improving Windows 98 performance in a number of areas.

Memory Optimization

One of the first things to look at is how the physical RAM in the system is working. Extremely common performance problems arise from inadequate RAM for the demands being placed on the system. This is closely related to virtual memory optimization, discussed in the next section.

Memory problems can be caused by the following:

There could be inadequate RAM for the demands being placed on the system.
Crashed applications can still consume system RAM, causing inadequate RAM.
Applications might not be freeing up memory resources appropriately (called memory leaks).
Windows 98 maintains three key shared memory resources: System, User, and GDI. These resources can fall to dangerous levels, causing unpredictable behavior on the system.
Some applications cause excessive memory fragmentation over time.

To determine if there's inadequate RAM, you can use Windows 98's System Monitor to look at available memory and swap file utilization. Compare Allocated Memory to the amount of RAM in the system. If the Allocated Memory counter in System Monitor is significantly higher than the amount of installed RAM (look for a 2:1 or 3:1 ratio of allocated:installed RAM), then you need to improve the RAM situation. You can run fewer programs, remove unneeded applications or system services, or add more RAM to the system. You generally don't want Allocated Memory to exceed double the amount of installed memory.

To examine shared memory resource utilization, run the Windows 98 Resource Meter, which displays a percentage utilization for each of the three key shared memory resources in Windows 98. If any of these fall below 15%, you can have problems with the system's behavior, including performance problems. When this happens, restart the system and immediately run Resource Meter, and refer to it as you perform the tasks leading up to the performance problem. Once you've identified which step or program is causing the resource levels to fall precipitously, you can look for alternatives that make fewer demands on the shared resources.

If you think the cause is a previously crashed application, restart the system and use System Monitor to see if the available memory levels are significantly improved when the steps leading up to the performance problem are duplicated.

TIP: Unfortunately, software bugs can cause unpredictable, seemingly random behavior on a system. Over time, these problems can accrue and can cause performance problems, even when the system otherwise appears to be running well. The first order of business when addressing any performance complaint is to do a complete restart of the computer in question. If nothing else, the restart ensures that you're working with a clean slate before you spend a lot of time working on a problem. Memory-related performance problems, in particular, often are resolved with a clean restart of a system.

Virtual Memory Optimization

The most common way that inadequate RAM expresses itself is through excessive use of the paging file. The performance danger is a condition known as thrashing, in which the running applications require more system memory than there is RAM, and so memory pages are furiously paged back and forth from the system paging file to try to meet all the demands. When this happens, virtually every memory access by an application requires that a memory page be brought back into RAM from the paging file (and some pages moved back to the paging file), which causes extreme performance problems. Thrashing is the biggest
performance-killer you can have!

Sometimes a lot of disk access by an application can cause what appears to be thrashing, when it is really just a lot of normal disk reads and writes. Before concluding that a system is thrashing, you need to look at some performance information. Using System Monitor, examine the counters for Page-Ins and Page-Outs, which indicate the number of pages being paged in and out of the swap file. If these numbers are relatively low and are more "bursty" than steady, then the problem may not be thrashing. You can also compare Page-Ins and Page-Outs with Disk Reads and Disk Writes to see what percentage of disk activity is due to application file reads and writes versus page file activity.

NOTE: The terms page file and swap file are synonymous in Windows 98, and you will often see these terms used interchangeably. This is technically incorrect: Windows 98 uses paging and a page file exclusively and does not perform swapping or use a swap file. The terms swapping and swap file are actually holdovers from Windows 3.1, which used swapping of 64KB pieces of memory for its virtual memory rather than the paging of 4KB pages of memory that Windows 98 actually uses.

There are only a few ways to deal with thrashing when it occurs:

Increase the amount of RAM in the system to eliminate the cause of thrashing.
Reduce the amount of RAM needed by reconfiguring the applications, removing unneeded system services (such as network protocols that aren't being used), or running fewer applications at a time.
Try to optimize the paging file's activity.

To optimize a paging file's settings, use the Performance tab of the System Control Panel and click the Virtual Memory button. This activates the Virtual Memory dialog box shown in Figure 35.1.

Figure 35.1

You can optimize the system's virtual memory settings with the Virtual Memory dialog box.

To optimize the settings for virtual memory, use these tips:

Relocate the virtual memory file to the most active partition of the least active physical disk. You choose the least active physical disk to ensure that the disk heads on the disk are free to work with the paging file, and you choose the most active partition on that disk to ensure that the disk heads are most often in the general vicinity (partition) of the physical location of the swap file.
Make sure that the swap file location isn't conflicting with the location where an application is reading and writing files. To optimize a system for a particular application, the ideal situation is to have Windows itself on its own disk drive, the application and its data files on their own disk drive, and the paging file on its own disk drive. If you have only two disks, locate Windows and the paging file on one disk, and the application and its data on the second disk. If you have one hard disk partitioned into many partitions, you'll probably have the best luck with Windows, its paging file, and the application and its data files all on a single partition.
Periodically check System Monitor to see how large the Swap File In Use counter reads. Set the Minimum setting on the Virtual Memory dialog box to be equal to or greater than the largest Swap File In Use size you've seen. This ensures that the system never has to waste time increasing the size of the paging file as system demands increase.
While not a performance-improving setting, make absolutely sure that the Maximum setting in the Virtual Memory dialog box leaves adequate room for the heaviest-possible virtual memory needs.
If you relocate the paging file to another disk, make sure you completely defragment the disk before relocating the paging file; this ensures that the resulting paging file is as defragmented as possible when it is created.

File System Optimization

Windows 98 can use one of two file systems: FAT16 or FAT32. In certain situations, FAT32 performs better than FAT16, depending on the partitioning of the hard disks and their performance characteristics. Included in Windows 98 is a tool that lets you easily upgrade a FAT16 file system to FAT32. However, keep in mind that as of the time of this writing, Windows NT does not support the FAT32 file system, and so a computer dual-booting both Windows NT and Windows 98 is not able to see or work with FAT32 partitions when running Windows NT. Also for this reason, you cannot upgrade the primary boot partition to FAT32 if you want to dual-boot Windows NT.

Because of the way that FAT (both FAT16 and FAT32) allocates space on hard disks, over time files may become fragmented, where a single file will have its contents spread over many different, noncontiguous areas of the physical disk. You can perform a defragmentation to periodically relocate all of the files on a disk so that they are contiguous, which improves performance.

To defragment a disk, right-click on the disk in Explorer or My Computer and choose Properties. Move to the Tools tab and click the Defragment Now button. Defragmentation proceeds immediately. On large disks with many discontiguous files, defragmentation may take 20 minutes or more to complete. It's a good idea to train your users how to do this, so that they can periodically run this process. You can also use the Scheduled Tasks feature of Windows 98 to schedule automatic periodic defragmentations.

File system performance problems are sometimes caused by errors in the file system. Cross-linked files, lost clusters, and even marginal areas of the disk can cause the system to operate more slowly than expected. It's a good idea to do a full test of the disk before proceeding with detailed performance work. From the Tools tab of the disk properties dialog box, click Check Now to start ScanDisk, and make sure you click the Thorough button to perform a complete surface test with ScanDisk.

Generally, compressing a hard disk drive with DriveSpace causes reduced system speed, because the system must compress and decompress data written to and read from the disk for every disk read and write. However, some applications may actually perform faster on a compressed drive. If you consider a disk-bound application (meaning disk performance is the bottleneck) that uses very large, very compressible files, then the added overhead of the disk compression may be more than offset by having to read and write fewer actual bytes to the disk. For example, consider an application that reads and writes to a 50MB file that largely has repeated data in it. If the application reads 1MB of data at a time, and with compression that 1MB of data actually takes only 100KB on the compressed drive, then the system has to transfer only the smaller amount from and to the disk. On computers that have very fast processors but very slow disk drives, disk compression can help the applications to run faster because of the reduced need to transfer data to and from the drive. Unfortunately, you simply have to test this if you suspect it might help. You can always uncompress a drive if compressing it didn't help, or if it hinders performance.

Hard Disk Optimization

How you configure the hard disks of a system has a lot to do with how well they perform. On Windows 98 systems, EIDE and SCSI hard disks perform comparably if the hard disk speed is the same. However, if you can configure the disks in the system so that they spread their activity across multiple controllers, this can make the system perform better. For example, many newer systems have two EIDE controllers on their motherboards. If you have two hard disks in the system, consider connecting each disk to its own EIDE controller rather than having both of them on a single controller. This reduces contention on the EIDE bus. Also consider any impact from using the CD-ROM drive, which may also use an EIDE connection to the system. If the performance problem exists when the CD-ROM is being constantly accessed by an application, consider moving the CD-ROM to its own EIDE controller, or consider upgrading to a SCSI-based CD-ROM that doesn't contend with the hard disks at all.

NOTE: Under Windows 98, most EIDE disk systems perform on par with most SCSI disk systems. Windows NT is a different story, however, where SCSI disk systems almost always outperform EIDE disk systems. This difference in performance occurs because Windows NT takes much better advantage of certain SCSI features such as Scatter/Gather and Connect/Disconnect.

If your system is using an EIDE or SCSI controller on an add-on card that is connected to an ISA or EISA bus, consider upgrading to a PCI or VESA controller. The improved performance of the PCI or VESA buses pays off nicely in terms of disk performance.

Graphics Optimization

There are unfortunately not many tuning steps you can take to improve graphics performance. First, you need to identify whether you're experiencing a graphics-based performance problem or something else. You generally know that a performance problem is graphics based when you experience inadequate performance when heavy screen updating is taking place, when images are "jerky" as they update, or when there is little else happening on the system (such as CD-ROM reads or hard disk reads and writes).

NOTE: There are many downloadable utilities that can help you test the graphics performance of a system. One of the best is the WinBench program from Ziff-Davis. Go to the site www.zdbop.com to download the latest version of WinBench.

Graphics performance on a system is mostly a function of the display adapter installed into the system and the bus type into which it is installed. Because so much data is written to a graphics controller, install one that uses the fastest bus in a system, such as the PCI bus. Other tips for improving graphics performance include the following:

Check with the vendor for updated display adapter drivers. Often, newer drivers include performance improvements that the vendor has discovered and implemented.
On systems with very slow graphics subsystems, use the lowest resolution and color depth needed for the application. This can drastically reduce the amount of data that needs to be written to the graphics adapter, often by as much as several orders of magnitude when complex bitmaps are rendered on the display.
Fortunately, graphics adapters aren't terribly expensive. You may be able to upgrade to a much faster, more optimized adapter for as little as $200.
On the Performance tab of the System Control Panel, click the Graphics button to open the Advanced Graphics Settings dialog box shown in Figure 35.2. Make sure the slider is set to Full. You should set this slider to a lower value only if you are experiencing functional problems with the display output.

Figure 35.2

Make sure the slider in the Advanced Graphics Settings dialog box is set to Full.

Optimizing Printing

Printing performance problems can have a lot of impact to users' productivity. If a user needs to wait for 30 minutes for a report to finish printing, and the printer is taking an inordinate amount of time to print each page, then you probably have a printing performance problem that you can address.

NOTE: For network-based printers, the information in this section along with information in the later section "Optimizing Network Performance" will address improving printer performance.

Before looking at the printing subsystem for a suspected printing performance problem, first ensure that the problem does not originate elsewhere. For instance, some applications may be experiencing a performance problem in their ability to collect and output data, and the printing subsystem itself may be running just fine. You should carefully analyze the application's behavior while printing to determine if the printing subsystem is the bottleneck, or if it's something else limiting the collection and organization of data for the printout. The best way to do this is to measure printing performance with similar applications that create similar types of output. If the other application prints fine, then you should suspect the application that's experiencing the problem first.

There are three main areas that affect printing performance:

The rendering of the printed pages on the system before they are sent to the printer
The transmission of the printed data to the printer
The speed of the printer to render printed output and to move the pages through the print process

You measure printing performance in Windows 98 by using two measurements. The first is called Return to Application (RTA) speed; it is the speed at which the application becomes responsive again once the print command has been issued. The other measurement is called printer page drop speed; it is the speed at which the print job is completed after the print command is issued. Before proceeding, determine if your problem is with the RTA speed or the printer page drop speed.

Printer Rendering and Spooling

Before output is sent to the printer, it is typically spooled to a file on the local hard disk, and certain operations may take place on the printed output at this stage. This area is a common source for printing performance slowdowns. If, when the print command is issued, it seems that there is excessive disk activity before the printer starts outputting pages, then you want to examine this area for improvements.

Start by opening the printer's Properties dialog box. Open My Computer, then Printers, and then right-click on the printer and choose Properties. Move to the Details tab and click on the Spool Settings button, which reveals the dialog box shown in Figure 35.3.

Figure 35.3

The Spool Settings dialog box.

To maximize the RTA speed, choose Spool Print Jobs so Program Finishes Printing Faster and then choose Start Printing After First Page Is Spooled. On slower computers, you night achieve better print performance by choosing Start Printing After Last Page Is Spooled.

To maximize the printer page drop speed, choose Print Directly to the Printer. The application will stay busy until the printout is complete (or at least until it's fully sent to the printer's memory) but the system will be free to devote all of the processor time to composing the print pages, and so the printer page drop speed will be best with this setting.

By default, Windows spools printer output to the disk by using the Enhanced MetaFile (EMF) format. This spooler format offers the best performance. The alternate spooler format, RAW, may solve printing problems but is also slower than EMF.

Printer Transmission Speed

The speed at which the computer can send data to the printer can play a major role in printing performance. To maximize transmission speed performance, follow these guidelines:

If you have a choice, use a parallel printer connection rather than a serial connection. Parallel ports transmit data much faster than serial ports.
Always use a high quality printer cable. Cables that allow electrical noise or that have poor connections can slow printer output, and can also cause quality problems in the printouts.
If the computer lets you configure a parallel printer port for ECP mode, and the printer supports it, choose it. ECP-configured ports operate much faster than standard parallel interfaces.

Printer Rendering Speed

Most print jobs are composed of both text and graphics mixed on each page. Complex instructions are sent to the printer to render this information into the printed result. On complex jobs, a lot of processing is required by the printer. For instance, PostScript printers require quite a bit of processing in order to compose most pages.

NOTE: Some of the properties tabs discussed here may be different (or nonexistent) for your printer because the tabs are dependent on the printer driver installed. The options discussed in this chapter are common for HP LaserJet printers; your printer could have different options.

You can make some adjustments and choices that might improve the rendering speed for print-outs. Using the printer's Properties dialog box, move to the Fonts tab as shown in Figure 35.4.

On the Fonts tab, experiment with different settings for how fonts are downloaded to the printer. Downloading TrueType fonts as either bitmap or outline soft fonts will generally print the fastest, while printing TrueType fonts as graphics often improves their appearance and can be faster for pages that are largely graphic with little text.

Figure 35.4

The printer's Properties dialog box showing the Fonts tab.

Another setting that changes how the printer renders pages can be found in the Graphics tab, shown in Figure 35.5. Use the Resolution setting to change how many dots per inch are printed. If the printout contains few, simple graphics and speed is important, a lower resolution may help. Also, select Use Vector Graphics whenever possible, as they are often much faster than raster graphics for the printer.

Figure 35.5

The printer's Properites dialog box showing the Graphics tab.

The job of rendering graphical pages is incredibly complex, and often requires a speedy processor in the printer itself, along with a lot of memory. If printer rendering speed is slowing you down, you might be forced to get a faster printer. Generally, more expensive printers include much faster processors and render pages much more quickly.

If you have a choice, PostScript printers almost always render graphical pages more slowly than other technologies, such as HP's Printer Control Language (PCL). Many PostScript printers also support PCL, so use them in the faster PCL mode as long as your print jobs render correctly in that mode.

Network Optimization

Optimizing the performance of networks requires a book all its own, but there are some common things you can do that can have a large impact on any network-connected computer. The first order of business is to isolate the network as the source of the performance slowdown. Believe it or not, applications running over a network, with their files stored on a remote file server, often perform better than applications running purely on a local computer. With a network that isn't very busy and that has adequate hardware for its servers, this is often the case. So the first thing to do is find out whether or not the network is actually causing problems. Things to look for here include comparing the speed of one computer to others that run the same application over the network, to see if just the one computer is having a network-specific problem, and trying to run the application purely from local hard disks to eliminate the network from the problem temporarily. Doing both things will start to give you a feeling for how the network is impacting an application's performance.

Network performance problems fall into two broad categories: performance problems due to the design of the network, and performance problems that involve the network interface on a particular computer. Following are some tips for optimizing network performance in both of these categories:

Try running client/server applications with TCP/IP instead of IPX/SPX if you have a choice. TCP/IP generally supports larger packet sizes than IPX/SPX, and so performance is sometimes better depending on the application and the bottleneck. IPX/SPX is also the more "chatty" protocol and sends and receives a lot more status information than TCP/IP, so an IPX/SPX-based network tends to be busier than a TCP/IP network.
It sounds simple, but it's easy to overlook this one: A bad network cable can often play a large role in poor network performance. Even on 10Base-T networks, you may want to try swapping the cables from the wall to the network computer and from the patch panel to the hub to isolate the network cabling. If all else fails, you can also move the computer to a different node (one that is known to operate normally) on the network to make sure in-wall wiring isn't to blame. This author once saw a workstation that performed at about 10% of its speed because of a 10Base-T patch cable from the wall to the computer. Swapping it fixed the problem. The insidious thing was that the computer basically worked on the network. The trouble was due to excessive retries required when large amounts of data needed to be transmitted to the workstation. The same thing can happen with 10Base-2 (Thin Ethernet) networks, too.
Make sure to remove any protocols and other network service software that isn't needed for a computer because unneeded protocols and services sap performance, even when not being used. Use the Network Control Panel to remove any unneeded network service software from the unit.
If you have manageable hubs, check the port statistics for the computer in question. These statistics may give you a clue as to what's happening. You'll want to compare the port statistics with the overall hub and network statistics, too. Check for statistics indicating short packets (runt packet) and long events. Also, take a very close look at the collision statistics on Ethernet networks. The number of dropped packets due to collisions shouldn't exceed 5% of the total number of packets transmitted; if it does, consider breaking the network up into smaller networks.
Network interface cards (NICs) sometimes go bad. Try replacing the NIC for a computer experiencing network performance problems.
If you have a 100Mbps backbone for the network and the client computer has a 10/100- Mbps NIC, you can try moving the workstation directly onto the backbone to see if the problem is bandwidth-related. Some applications do move enormous amounts of data across a network, and may require the higher bandwidth connection to their server. (Of course, the server in question must also be on the backbone for the workstation to benefit from this test.)

Solving network performance problems can be difficult, even at best. Just remember to work through all the possible bottlenecks between the workstation and server in a methodical fashion, and you're sure to find the bottleneck and can then work to resolve it.

Optimizing Application Performance

Up until now you've learned only about performance tips for different areas of the computer and its support mechanisms. However, performance complaints are often related to a specific application's speed. Sometimes you can make changes in the application itself that solve its performance problems. Consider the following ideas when thinking about application performance:

Are you using the latest update of the application, and have you discussed the performance problem with the application vendor? Vendors often know about common sources of poor performance with their applications, and can usually give you very good advice for tuning their application or configuring a computer to optimally support their application. Turning to the vendor of the application for help can often save you a lot of time when solving a performance problem.
Try locating the application and its data files on a different partition. You may get markedly better performance on different drives, particularly if they use a different file system. Don't forget that network shares are also drives that you can use to test this; sometimes applications run faster on a network share than they do locally.
Make sure no other applications are running when you test the application. Contention for the system may impact one application even when it appears that others are running fine.
Installed utility programs can sap a computer's performance. Remove any unnecessary utilities from the system's Startup folder. Common sources of trouble include third-party screen savers, Microsoft Fast Find, and sometimes Office Startup.
A subsequently installed DLL may slow an application. You should try reinstalling any applications that are performing poorly. Similarly, sometimes a key application file is damaged on the system's disk, and this may not cause an actual error that you can diagnose and solve, but it may cause performance problems. Completely remove the application and reinstall it if you suspect this might be the case. Use Windows 98's Version Conflict Manager and System File Checker to examine these possibilities.
For DOS applications, tweak the settings in the program's Properties dialog box, particularly these:
Set to run in a full screen rather than a window
Avoid using the Protected checkbox on the Memory tab
Turn off any memory support types not needed by the application
Set the idle sensitivity to low
Turn off Mouse Quick Edit, and turn on mouse exclusive mode
Turn off Allow Screen Saver
On the Screen tab, turn off Dynamic Memory Allocation
Turn on Fast ROM Emulation
All of these DOS program settings can improve performance, sometimes dramatically.
For Win16-based applications, make sure that no other Win16 applications are running at the same time. This avoids problems arising from poor cooperative multitasking within the Win16 virtual machine.
For Win32 applications, there is nothing in Windows 98 itself to tune their performance (you can tune the system, but you can't do much to change how the application runs). However, you can try running the application under Windows NT, if possible. A specific application may perform much better under Windows NT Workstation than Windows 98. This isn't often the case, but sometimes it is, especially if the application can benefit from any NTFS-formatted partitions on the Windows NT system. For example, a client/server client application that this author recently tested generally performed much better under Windows NT. Not only did it perform better, but many copies of the application could be run simultaneously under Windows NT, whereas it was really possible to run only one copy under Windows 98. This benefit is very application-specific, however; some applications may run faster under Windows 98. When in doubt, test it!
Applications sometimes don't relinquish memory objects properly over time. You can identify such problems with System Monitor (discussed later in the section "System Monitor") and can restart the application periodically to automatically free up all the resources initialized by the application.

Using Windows 98 Performance Tools

There are several tools included with Windows 98 that play a key role in optimizing the performance of the system. In this section, you learn about these tools. Other tools that are more directed to troubleshooting are discussed in Chapter 37, "Tools and Strategies for Troubleshooting Windows 98." These other troubleshooting tools, however, can also play a role in solving a performance problem, particularly when the performance problem is due to actual trouble in the system rather than a bottleneck of some sort. When working with a thorny performance problem, don't overlook the troubleshooting tools discussed in
Chapter 37.

Windows Tune-Up

Windows Tune-Up is a program that leads the user through a series of performance optimizations on a Windows 98 computer. New to Windows 98, Windows Tune-Up makes it easy for the average user to do some of the things that used to require the skills of a person with more training.

Windows Tune-Up walks the user through the following tasks, step by step:

Disk Cleanup is run to remove any unnecessary files from the system's hard disks.
ScanDisk is run to check for errors on the hard disks.
Disk Defragmenter is run to defragment the contents of the hard disks on the system.

Although you can perform all of these optimizations manually, you can instruct users to run Windows Tune-Up, an easy program that will painlessly lead them through all these steps.

Resource Meter

Resource Meter is a small application that monitors the amount of shared resource memory available on a Windows 98 system. You can find it in the System Tools folder (Start menu, Programs, Accessories, System Tools). Running this application displays a small meter on the TaskBar. You can keep an eye on it when working through the steps of a performance problem to see if inadequate system resources are related to the problem. Hovering the mouse pointer over the meter will display the percentages free for each of the three main shared memory resources in Windows 98: User, System, and GDI. You can also double-click on the meter to display the dialog box version of the display, shown in Figure 35.6.

Figure 35.6

Resource Meter can show you if inadequate shared resources are causing a performance problem.

System Monitor

Windows 98 includes a system monitoring tool that is extremely helpful when diagnosing performance problems. System Monitor, shown in Figure 35.7, offers you a wealth of information about what is happening on a system and should be a core tool in your performance-tuning toolbox.

Figure 35.7

System Monitor displaying line charts.

Within System Monitor, you can select from a number of different performance counters available in Windows 98. You add and remove them as needed. System Monitor also supports three different ways of displaying performance counters: line charts, bar charts, and numeric charts. You can see a sample line chart in Figure 35.7, while Figures 36.8 and 36.9 show examples of bar and numeric charts.

To add a new counter to System Monitor's display, access the Edit menu and choose Add Item. You see the Add Item dialog box shown in Figure 35.10.

Figure 35.8

System Monitor displaying bar charts.

Figure 35.9

System Monitor displaying numeric charts.

Each performance counter category is listed in the Category listing; selecting one reveals the actual performance counters available in that category in the Item list. You can select multiple counters to add by holding down the Ctrl key while you click on each one, then click OK to add them to System Monitor's display. Consider the following tips for performance counters to watch as you duplicate a performance problem:

You will always want to monitor Kernel: Processor Usage to see the approximate percentage of time that the processor is busy. Some performance problems are due to the speed of the processor. Also, check this value when the computer appears idle; a background process may be consuming more processor time than you realize.
Watch the activity in Memory Manager: Page Faults, Page-Ins, and Page-Outs to see if the system is thrashing.
You can get a sense of how disk-bound an application is by looking at File System: Bytes Read/Second and Bytes Written/Second. You may also want to watch File System: Reads/Second and Writes/Second to approximate the efficiency of the reads and writes (you generally want the most bytes per read and write, although you can't often control this within an application).

Figure 35.10

System Monitor's Add Item dialog box.

Table 35.1 lists the performance counters available along with descriptions of what they monitor. that Windows 98 offers many additional performance counters compared to Windows 95.

Table 35.1 System Monitor Performance Counters

Category	Counter	Notes
Dial-Up Adapter	Alignment Errors	Number of serial port alignment errors; may indicate a bad port or cable.
	Buffer Overruns	Number of times the serial buffer was overrun; check the error control and handshaking settings to improve this.
	Bytes Received/	Number of bytes received per second through the
Second	dial-up adapter.
	Bytes Transmitted/	Number of bytes transmitted per second through
Second	the dial-up adapter.
	Connection Speed	Reported connection speed in bits per second.
	CRC Errors	Number of Cyclic Redundancy Check (CRC) errors.
	Frames Received/Second	Number of frames received by the dial-up adapter per second.
	Frames Transmitted/Second	Number of frames sent through the dial-up adapter per second.
	Framing Errors	Number of framing errors within the serial port of the dial-up adapter.
	Incomplete Frames	Number of incomplete frames received.
	Overrun Errors	Number of overrun errors within the serial port.
	Total Bytes	Total number of bytes received since System
Received	Monitor was started.
	Total Bytes	Total number of bytes transmitted since System
Transmitted	Monitor was started.
Disk Cache	Cache Buffers	Number of current buffers in the cache.
	Cache Hits	Number of times a request for data was satisfied with data in the cache. You want this number to be as high as possible; if it seems too low, reducing memory load may let the cache grow larger, possibly increasing the likelihood of finding needed data in the cache.
	Cache Misses	Number of times data was not found in the cache and had to be read from the disk. Optimally, this number should be as low as possible; reducing memory load may help reduce this value.
	Cache Pages	Number of pages stored in the cache.
	Failed Cache	Number of times a cache recycle request failed;
Recycles		generally indicates that the cache is full and there is little available memory in the system.
	LRU Cache	Number of times the cache is searched, from oldest data to newest, to find buffers that can be freed up. This happens when new data needs to be added to an already full cache, and when the system needs to reduce the cache size and use its memory for other purposes. You should see only very occasional cache recycles, optimally.
	Recycles
	Maximum Cache	The maximum number of cache pages stored since
Pages	System Monitor was started.
	Minimum Cache	The minimum number of cache pages stored since
Pages	System Monitor was started.
	Random Cache	Number of times the cache was randomly searched
Recycles	for buffers that could be freed up.
File System	Bytes Read/Second	Number of bytes being read from all file systems per second.
	Bytes Written/	Number of bytes being written to all file systems
Second	per second.
	Dirty Data	Number of bytes in the cache waiting to be written to a disk. that dirty data is stored in blocks, so the bytes reported here may be larger than the actual bytes to be written; it is a count of the total bytes in the waiting blocks rather than the bytes within the blocks.
	Reads/Second	Number of read operations per second for all file systems.
	Writes/Second	Number of write operations per second for all file systems.
IPX/SPX-	IPX Packets Lost/	Number of IPX packets that were ignored for some
Compatible	Second	reason, often because they were incorrectly formed.
Protocol
	IPX Packets	Number of IPX packets received and accepted per
	Received/Second	second.
	IPX Packets Sent/Second	Number of IPX packets sent by the computer per second.
	Open Sockets	Number of currently open IPX sockets.
	Routing Table	Number of IPX network routes listed in the
Entries	system's routing table.
	SAP Table Entries	Number of received service advertisement packets (SAP).
	SPX Packets	Number of SPX packets received per second.
Received/Second
	SPX Packets Sent/Second	Number of SPX packets sent per second.
Kernel	Processor Usage	Percentage utilization of the processor at any given second.
	Threads	Number of threads running in the system at any given time.
	Virtual Machines	Number of virtual machines running in the system at any given time.
Memory Manager	Allocated Memory	Total amount of memory in use by the system and applications.
	Discards	Number of pages that have been removed from memory because they're no longer needed in RAM.
	Disk Cache Size	The current size of the disk cache; Windows 98 adjusts the cache size aggressively based on the needs of the system, so this value may change rapidly when memory load changes.
	Instance Faults	Number of instance faults per second.
	Locked Memory	Amount of allocated memory that is locked (and is therefore unswappable).
	Locked Non-cache	Number of locked memory pages that are not part
Pages	of the cache.
	Maximum Disk	Largest possible size of the disk cache based on
Cache Size	system configuration.
	Mid Disk Cache	The mid disk cache size based on a moving
Size	average.
Cache Size	Minimum Disk	Smallest possible disk cache size based on system configuration.
	Other Memory	Amount of non-pageable allocated memory.
	Page Faults	Number of page faults per second. A page fault occurs when memory is requested that is not present in RAM but is instead in the swap file.
	Page-ins	Number of pages moved into RAM from the paging file per second.
	Page-outs	Number of pages moved into the paging file from RAM per second.
	Pages Mapped	Number of memory pages mapped from the cache; from Cacheused with memory-mapped files.
	Swapfile Defective	Number of defective bytes in the swap file, in increments equal to the page size (4KB). A defective swap file page can be caused by disk read and write errors.
	Swapfile in Use	Number of in-use bytes stored in the paging file.
	Swapfile Size	The current size of the paging file.
	Swappable Memory	Number of bytes that can be stored in the paging file at any given time.
Microsoft Client Networks	Burst Packets Dropped	Number of IPX/SPX burst packets that were for NetWare received damaged and dropped.
	Burst Receive	Microseconds of gap between burst packets.
	Burst Send	Microseconds of gap between outgoing burst packets.

Gap Time	Bytes in Cache	Number of network bytes being cached by the network client.
	Bytes Read per Second	Number of bytes read through the client per second.
	Bytes Written per Second	Number of bytes written through the client per second.
	Dirty Bytes in	Number of bytes of write-behind data in the
Cache	client's cache waiting to be sent over the network.
	NCP Packets Dropped	Number of NCP packets received damaged and dropped.
	Requests Pending	Number of server requests waiting for a response from the server.
Microsoft Network Client	Bytes Read/Second	Number of bytes read per second through the client.

	Bytes Written/ Second	Number of bytes written per second through the client.
	Number of Nets	Number of networks known to the client.
	Open Files	Number of files open through the network client.
	Resources	Number of resources being used by the client.
	Sessions	Number of network sessions open by the client.
	Transactions/	Number of transactions second being processed per Second
Microsoft Network Server	Buffers	Number of buffers allocated by the server.
	Bytes Read/Sec	Number of bytes read by the server per second.
	Bytes Written/Sec	Number of bytes written by the server per second.
	Bytes/Sec	Number of bytes read or written by the server per second.
	Memory	Amount of memory being used by the server.
	NBs	Number of network buffers maintained by the server.
	Server Threads	Number of threads being used by the server.

System Monitor does exact a small performance penalty through its monitoring activities. However, the impact will be relatively small and should be balanced in terms of not causing radical changes in how single aspects of the system are performing.

Other Performance Tools

If all the tools discussed in this chapter fail to resolve or characterize a performance problem for you, you'll need to turn to third-party tools for additional assistance. These other tools fall into two broad categories: system performance-measuring tools and application-measurement tools.

There are many third-party programs that can measure the performance of a system in different ways and report on the results. You can run an initial test to measure the base case, and then make configuration changes and rerun the tests. It is important when doing this to ensure that the system's performance is causing the performance complaint, and not specific application behavior. You can find an excellent set of tools to measure system performance from Ziff-Davis at the www.zdbop.com Web site. There are many others as well, available at any site that carries shareware and freeware software. Utilities exist to measure disk speed, graphic speed, and memory speed.

Application-measurement tools are less powerful, but are important for testing an application's performance. Key to this effort is the ability to script a set of application commands that demonstrate the performance problem. Depending on the application, you may then be able to build a batch file that causes the application to start and the script to execute, or you may be able to find tools that will duplicate user involvement precisely for the application and wrap the results within a timer. Once you can do this, you can start making changes and retesting. Or, you may be able to build a program in an application's programming language that times a set of operations and displays the results, which you can then use for benchmarking the performance problem.

Windows 98 Configuration
Recommendations

You can have the most perfectly tuned system in the world, but if it is fundamentally unable to offer the performance needed, you won't be able to find magical ways to solve its performance problems. You need to start with a system that is adequately sized to meet the demands you need to place on the system.

For general desktop application work, a computer with a Pentium 133 is perfectly adequate. It is more important that the system have enough RAM to meet the needs of the applications. For a busy desktop computer running Windows 98 and, for example, Microsoft Office, at least 24MB of RAM will yield good performance, but 36MB of RAM is preferred (and you may still see improvements up to 48 or 64MB of RAM). Most performance problems are due to inadequate RAM, so be sure to use the information in this chapter to look carefully at memory load before deciding that a system needs more RAM.

For heavy application development work or heavy database application work, a more powerful computer is called for. You should try to use a system with at least a Pentium 200 or faster processor, and, more important, the system should have 64MB or more of RAM. While this may seem like a lot, RAM prices have fallen to incredibly low levels, and you can purchase and install this much RAM inexpensively relative to the performance benefit realized.

It is best to use systems with Enhanced Data-Out (EDO) RAM when possible. EDO RAM performs much faster than traditional RAM. Also, depending on your need for reliability, you should think about using a computer that uses parity RAM or ECC RAM, both of which can detect memory errors if they occur. Many inexpensive computers lower their price by avoiding parity or ECC RAM, but such systems can produce erroneous results when a memory chip isn't working properly.

Many applications rely on speedy disk subsystems. Always purchase the fastest hard disks you can find; they don't cost a lot more than their less-expensive brethren, but the performance boost can be significant. It's also important to get the fastest disk controller you can, and it should be made for the fastest bus in the system (usually the PCI bus). If the system has more than one disk controller and you are using more than one disk, spread the load of the disk drives across the different controllers whenever possible.

]NOTE: As Robert Heinlein was fond of saying, "There ain't no such thing as a free lunch" (TANSTAAFL). As a rule, more expensive component choices will perform better than less expensive components. While there are always exceptions to the rule, the rule is true much more often than not. It's easy to find inexpensive computers that actually perform much more poorly than other computers, even when the other computers use slower processors! This is because the other components of the computer don't perform well, and moreover don't work together well. Be sure to buy system components wisely, but don't be penny-wise and pound-foolish.

With regard to the other components of the system, purchase the best ones you can find that meet the needs of the applications that will be run. It's important to know the exact demands that will be placed on the system, as some components make tradeoffs in performance because they are targeted to different types of application loads. For example, some graphics adapters are wonderfully fast when rendering 3-D images for game software, but may perform below average when handling standard Windows desktop rendering chores.

Conclusion

Improving the performance of a system is one of the most fun, most rewarding, most educational activities you can pursue in your systems work. Finding small changes that result in large improvements increases your knowledge of systems and Windows 98, and can pay off handsomely in user productivity.

In this chapter, you learned about the key performance areas of Windows 98 and also learned suggestions for improving Windows 98's performance in a number of key areas. You also learned about two tools that are valuable in performance-tuning a system: Windows Tune-Up (which runs other performance-enhancing tools: Disk Cleanup, ScanDisk, and Disk Defragmenter) and System Monitor. Finally, some recommendations for system selection were given that may help you to choose appropriate systems for the needs of the systems.

The next chapter, "The Windows 98 Boot Process and Emergency Recovery," shows you how to prepare for and handle emergency system recovery for a Windows 98 system. You also may want to continue in the same vein as this chapter by jumping to Chapter 37, "Tools and Strategies for Troubleshooting Windows 98," which is often a subject that goes hand-in-hand with performance tuning.