by Jay Milne  Server Performance: Benchmarking, Monitoring and Avoiding Bottlenecks Bottlenecks System bottlenecks exists in everywhere-from the low-end 486 NetWare 3.12 server to the multiprocessor Unix server. When one bottleneck is removed, another pops up. Your server often is only as fast as it slowest link or subcomponent. I have seen extremely well-equipped servers with multiple processors, hundred of MBs of memory and high-performance disks arrays, with a server connected to the network via a single 10-Mbps Ethernet segment. The administrators ask themselves why user performance seems so slow when the server is only 5 percent utilized. When trying to identify bottlenecks, look at the individual components of the system and how those components are connected. Lets look at each component and see what can be done to increase its performance. The most obvious component is the CPU . With the Pentium Pro processor from Intel, typically the CPU itself is no longer the bottleneck. But be sure to look closely at which CPU model you are using. The Pentium Pro comes in several flavors- the 166 MHz with 256 or 512 KB of Level 2 cache and the 200 MHz with 256 or 512 KB. The amount of Level 2 cache can have significant effects on performance. If you are running the computer as an application server, choose the large Level 2 cache. Intel soon will release Pentium Pro chips with higher clock cycles and with 1 MB of Level 2 cache. Another important component of the system is the main memory . When the application needs data, and it is not found in the cache, the CPU must go to main memory. Although memory is cheap and very fast, with speeds of 60 nanoseconds and below, CPU cache is faster but more expensive. In most instances, more memory is better. Current versions of Novell NetWare, both 3.12 and IntranetWare 4.1, do not support virtual memory . When the system runs out of free memory, it will become unstable and prone to abending. Virtual memory lets the operating system to be "fooled" into believing that there is more memory than really exists. This extra memory is stored on the disk subsystem. When the operating system needs data and is not found in either the CPU cache or main memory, it goes out to the virtual memory file on the disk. If the operating system must continually go to disk to get needed data, performance will suffer. This condition is often referred to as "paging" and indicates it is time to add more memory. Future version of IntranetWare will support virtual memory, which will help stabilize the system. However, it's not a panacea because performance will decrease if the operating system must get data from the disk rather than from main memory. There are some general guidelines for deciding how much memory to have in your system. A general rule is to buy as much as you can within your budget. Be careful, though, of how the memory is installed in your server. Often memory chips must be installed in pairs or groups of four. And your server might have only four, eight or even 16 slots. This can have a major impact as to what size memory you buy, (8-, 16-, 32-, 64- or 128-MB memory modules) and in what quantity. The last thing you want to do is to throw away memory in order to increase memory. For any critical application, always get error-correcting code (ECC) memory. It will cost a little more than plain memory but it will be worth it in the long run. There is no doubt NetWare 3.x and IntranetWare 4.x are highly efficient with system resources like memory. You can easily run a NetWare server with 12 MB of memory, (given that you are not doing any application hosting) but don't try that with Microsoft NT. My rule of thumb is to start an NT Server with no less than 32 MB and a NetWare server with 16 MB. Many factors will determine how much extra memory will be needed. Ask yourself how many users will be connected, how much disk space is needed (NetWare caches the directory entries for the disk), if the server be running any applications, such as a database, and what the characteristics of the use of the server are. For more detail on how to accurately calculate the amount of memory needed in a Novell environment, go to Novell's web site at www.novell.com and search for document # 2912047, Feb. 1997. The calculation involves adding the memory for the file system storage and caching, for the number of users connected and the applications that will be loaded. The next component is the disk subsystem , including the physical disks and the host adapters. Not too long ago 1 GB of disk space was considered huge. Now,1 GB is now the starting point for servers. Several factors affect disk performance. The characteristics of the disks themselves are very important. The rotational rate is the speed at which the individual disk platter spins. The current cream of the crop is 10,000 RPM. Having a fast rotational rate is good f or applications that require streaming data such as video or audio. The second characteristic is the speed of the read/write arm of the disk. The faster that the read/write head can move across the platter to find data the better. The aerial density of the disk platters themselves also is importance. Density refers to the amount of data in a certain physical area on the disk. The higher the density, the less movement is required to get the same amount of data. The number of disks that are in use should also be looked at. If you need 8 GB of disk space, buying one 8 GB disk is not the best choice in terms of performance and fault tolerance. A better solution would be to get four 2-GB disks. With more disks, you have more spindles spinning and thus more data can be written to the disks at the same time. This is easily exemplified in the TPCc benchmark tests where the disk is the common bottleneck and where more than 100 disks are used in one system-not for capacity but for performance. How these multiple disks are arranged is also important. But no matter the arrangement, you are implementing some form of RAID. RAID 0 provides no fault tolerance but offers very good performance. RAID 1 offers fault tolerance and performance, but at a cost. If your disk array uses five disks and you want to implement a RAID 1 array, you'll need to buy another five disks. The more common implementation is RAID 5, which offers a combination of both fault-tolerance and performance. RAID Levels Level 0: Disk striping Level 1: Disk mirroring Level 2: Redundancy through hamming code Level 3: Striped array plus parity Level 4: Independent striped array plus parity Level 5: Independent striped array with distributed parity Level 6: Level 5 with double parity Level 7: Independent striped array plus Level 10: Levels 1 and 0 Level 53: Levels 0 and 3 Another aspect of the disk array is the disk interface . For any server application, SCSI is the defaul t standard. Current SCSI implementations offer an up to 40 MB per second data-transfer rate, called SCSI 3 or Ultra SCSI. This SCSI implementation is virtually standard on servers. Never use IDE or EIDE for your disks. EIDE is fine for floppy or CD-ROM disks but it's not suitable for the multitasking, multiuser nature of a server. SCSI allows for connect/disconnect of SCSI commands, which lets multiple disk requests occur at the same time. The disk controller is another part of the disk subsystem. The most common implementation is a disk controller inside the server that is connected to the disks via a SCSI bus. The controller typically has onboard cache that helps increase performance by keeping recently used data in the faster cache-obviating the need to go to the disk drives to retrieve the data. The amount of cache can range from less than 1 MB to over 64 MB. The amount to use depends on the application and your budget-the more cache the better but at a higher cost. At some point you'll reach a point of diminishing returns. From my experience, at around 32 MB you start seeing less performance gain for the money. Server Performance Benchmarking Monitoring Tools Common Tips and Tricks Updated May 21, 1997 Print This Page E-mail this URL