Performance Analysis and Optimization of MS Windows NT Server, Part 2

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Updated : June 1, 1997

By Keith Cotton, Program Manager, PBS Training, Microsoft

Microsoft Tech • Ed 97 presentation (ENT408)

On This Page

Setting Expectations of System Usage and Availability
Forecasting Future Resources Allocation
Establishing a Plan for Long-Term Record Keeping
Analysis in the File and Print Server Environment
Resource Implications in the File and Print Server Environment
Considerations When Forecasting in a File and Print Server Environment
Calculating the Number of Users That a File and Print Server Can Support
Analysis in the Application Server Environment
Resource Implications in the Application Server Environment
Considerations When Forecasting in an Application Server Environment
Calculating the Number of Users an Application Server Can Support
Analysis in the Domain Server Environment
Resource Implications in the Domain Server Environment
Considerations When Forecasting in a Domain Server Environment
Calculating the Number of Users a Domain Server Can Support
Proposing Solutions

Setting Expectations of System Usage and Availability

Now that transactions have been defined and any system bottlenecks have been identified and resolved, the next step is to set expectations of system usage and availability. This allows the information systems or network analyst to estimate what the response time should be on a given server (when they are running a specific set of services and applications) with a certain number of users accessing the server concurrently.

When performing server analysis and optimization, consider analyzing the business plan of the organization. It is essential to know the business case and requirements for the system and network before starting to perform server analysis and optimization. When a customer says she wants a two-second response time, for example, she needs to be educated that the Windows NT Server network operating system can only affect a small percentage of that time, and it is the application and hardware that will affect the remainder of the time.

By specifying the limits on the system, and making everyone, especially management, aware of the limits and expectations, it is unlikely that any system responsiveness surprises will occur if everything is running within the ranges specified. If something does arise, use Performance Monitor or some other data monitoring application to collect and analyze the data to determine if system limits have been exceeded, or if bottlenecks have developed.

Note: More information on setting expectations of system usage and availability is presented in the upcoming modules.

Forecasting Future Resources Allocation

Good analysis of data over a period of time helps you to determine trends, to observe usage patterns, to detect bottlenecks, and to help plan for future upgrades and purchases.

Different methods can be used to forecast future resource requirements of a Windows NT system. Most data collection and monitoring tools, such as Performance Monitor, have the ability to perform some level of analysis with the data that is captured. Database applications, such as the Microsoft Access database, the Microsoft FoxPro® database, and the Microsoft SQL Server™ client-server database management system have the ability to import data from measurement tools, and then further query and analyze that data.

Any application capable of importing data and performing analysis on that data is useful when performing server analysis and optimization. The Microsoft Excel spreadsheet can be used to import and analyze database management information. A Microsoft Excel macro can take the data to be analyzed, and given certain criteria, generate a list of recommendations.

The following formula can help identify whether another Windows NT Server is needed:

1. Define the number of workload units on the server, such as client requests.

2. Capture the data that is relevant to the workload unit, such as data that would indicate how long it takes to transfer x bytes of data from server to client.

3. Multiply that number by the number of clients making similar requests.

4. Graph the number of workload units of input/output (I/O) over a specific period of time as a measure of how much can be finished in that period of time. Project the expected growth in workload units.

If the answer to number four meets the expectations of the customer, then the system should be able to accommodate the requirement, and no change is required.

If the answer to number four does not meet the expectations of the amount of workload units performed, this is an indication that further analysis or tuning needs to be completed. The results from further investigation may indicate the need to install another server.

Note: It is recommended to first test a pilot system in a controlled environment to determine "best case" values. Then, test in a production environment to determine how the existing environment affects the results of the pilot system.

Always plan server optimization on current requirements, such as what resources the applications currently require, the expected growth, and then forecast from those requirements. It is recommended that you double the best guess to come closer to actual implementation requirements.

The charting capabilities of Microsoft Excel can compile the data, graph the current use trends, and graph the expected trends, given specific business conditions identified in the business plan (expected number of users to be added, and so on). Variances should be graphed to show possible deviations from the expected performance and capacity numbers.

Note: To obtain a copy of the Forecasting Future Resources Allocation job aid, see "Job Aids" under "Course Materials" on the course Web page.

Establishing a Plan for Long-Term Record Keeping

As in all areas of computer analysis, documentation is essential. This is especially true with server analysis and optimization. Consistent and accurate record keeping will help identify trends as they are happening. Be sure to include baseline data, current activity data, and any other supporting data. This information can keep the organization's management informed of changes in the environment. It helps to build a case for budgeting requests, and to assist with problem identification and resolution.

Creating Management Reports

Once data has been added to the database and analyzed, an organization's management may request that reports be generated. Incorporate the following information into the management reports:

• Current usage patterns and trends from past data.

• A comparison of actual resource usage to resource usage expectations.

• Potential resource needs and budget considerations.

• An illustrated representation of current activity, with maximum and minimum values, along with predictions of expected activity over a specified time period.

The trend analysis these reports provide can also be used for preventative maintenance information. Use this information to identify where adjustments in the current environment are needed, and thereby avoid potential system bottlenecks that may render the system unusable.

In order to properly perform trend analysis, it is necessary to keep an extensive database of information for analysis of past trends and history.

Analysis in the File and Print Server Environment

A file and print server is usually accessed by users for data retrieval and document storage, and is occasionally used for loading application software over the network. Analysis of a file and print server focuses on the number of users accessing the server concurrently, and the amount of resource requirements that they are demanding. Numerous workload units are important when monitoring a file and print server.

Following is a list of common workload units for a file and print server and the respective Performance Monitor counter.

Workload unit	Performance Monitor counter
Concurrent user sessions	Server: Server Sessions
The number of files open	Server: Files Open
Average transaction size	PhysicalDisk: Avg. Disk Bytes/Transfer
Amount of disk activity	PhysicalDisk: % Disk Time
Type of disk activity	PhysicalDisk: % Disk Read Time PhysicalDisk: % Disk Write Time
Network use	Network Segment: % Network Utilization

Sometimes additional resources, such as server memory, are being consumed. If that is the case, add additional counters, such as memory counters, to the analysis to receive detailed information on the resource that is being accessed.

Resource Implications in the File and Print Server Environment

Memory and processor use have the greatest impact on file and print servers. The disk and network subsystems are important, though memory and processor have the greatest potential for being overused on a file and print server.

When monitoring a file and print server, be prepared to see numerous user connections; but many of those connections may be inactive. Consider adjusting the auto-disconnect setting for each file and print server environment.

Memory Implications

Memory is used for caching of opened files in a file and print server environment. Having enough RAM to allow for sufficient caching helps to improve performance when files are opened and continually accessed from the server.

Processor Implications

The processor is used for each network connection on the network; this means that all network connection traffic involves the processor. Having bus mastering network adapters and disk controllers helps to alleviate processing from the CPU, allowing more time for responding to data requests.

Disk Subsystem Implications

The disk subsystem is the primary server resource that users access. It will have a large effect on the overall perception of system performance, and ultimately, its capacity. The fastest and most efficient disk subsystem will provide the best overall performance improvement.

Network Subsystem Implications

A number of factors will affect the network subsystem (see the list in the Network Subsystem section). It will not matter how fast the disk subsystem is, how many processors are available, or how much RAM is installed in the server; if the network adapter card in the server is too slow, it cannot effectively perform transfers of data from physical network medium to RAM.

Considerations When Forecasting in a File and Print Server Environment

The following are some considerations and recommendations for forecasting in a file and print server environment.

Considerations	Recommendations
The number of users a specific server can support.	This is somewhat dependent upon the hardware of the server, and more dependent upon the type of transactions the clients perform on the server. Monitor the number of user sessions, and the effect each session has on the four major system resources using the counters introduced in the "The Basics Server Analysis and Optimization" module. The most common areas for potential bottlenecks are disk usage and network performance.
If users access the server to retrieve and update individual data files.	Consider the disk and network subsystems. Monitor disk and network objects to determine if any areas are being exposed as a bottleneck.
If the users access the server for data files and also to load their applications.	Add server memory to the list of objects to monitor. When opening files off the server, Windows NT attempts to cache the open files, which may cause a memory bottleneck.

Calculating the Number of Users That a File and Print Server Can Support

To calculate the number of users that a particular server can support

1. Test a single user making normal transactions on the server. Whether this transaction involves retrieving a word-processing document, a spreadsheet, a piece of electronic mail, or some other action, monitor the transaction using the appropriate counters relative to file and print servers as introduced earlier in this module.

2. Monitor the time it takes to complete a single normal transaction.

3. Monitor the resources used and multiply those by the number of users.

This produces a general capacity requirement. Once the amount of time it will take to accomplish the workload unit is determined, the result is compared to the desired number of workload units. If the results are not as expected, then:

• Analyze the system to determine the bottleneck. For a file and print server, start by monitoring memory.

• Calculate the amount of network traffic memory generates, as well as disk activity. The network subsystem can only accommodate x amount of data (10 MB for Ethernet, 4 or 16 MB for Token Ring, and so on). You can then determine projected use and whether it will exceed the network capacity.

If memory and the network subsystem seem to be able to handle the required load, then monitor the disk subsystem and processor utilization. If something is not functioning within given ranges, then either an improvement in the appropriate resource is required, or adding another server to distribute the load is necessary to satisfy the required number of workload units in the production environment.

Analysis in the Application Server Environment

The analysis of an application server largely focuses on workload units. An application server is accessed differently than a file and print server. Where a file and print server is traditionally accessed with fewer numbers of requests (with each request averaging a fairly large size), an application server is usually accessed with smaller, more frequent requests from the client computer.

In addition, the application server has the overhead of actually running an application using memory and processor resources.

The following table lists common workload units for an application server and the respective Performance Monitor counters for each workload unit.

Workload unit	Performance Monitor counter
Concurrent user sessions	Server: Server Sessions
Processor usage	Processor: % Processor Time
Average disk transaction size	PhysicalDisk: Avg. Disk Bytes/Transfer
Amount of disk activity	PhysicalDisk: % Disk Time
Network use	Network Segment: % Network Utilization
Average network transaction size	Will vary for protocol, such as NetBEUI: Frame Bytes/sec
Available memory	Memory: Available Bytes
Amount of paging	Memory: Pages/sec
Usage of cache	Cache: Copy Read Hits %

Also, some applications may provide Performance Monitor counters that give detailed application statistics. For example, Microsoft Exchange Server client-server messaging and groupware provides performance monitor counters and predefined charts. Additionally, Microsoft SQL Server offers numerous objects and counters specific to its operation, such as SQL Server: I/O Transactions per second and Cache Hit Ratio. Be sure to include any application-specific counters in the analysis of an applications server.

Resource Implications in the Application Server Environment

When monitoring application servers, such as in a Microsoft SQL Server client/server environment, more processor and memory use occurs than in the file and print server environment. Disk and network resources are also used consistently in this environment.

Memory Implications

Memory is used for the server portion of the client/server application. Make sure to add sufficient RAM to support operating system and application needs. The RAM required depends upon the particular system hardware and software configuration and needs.

Processor Implications

Applications run on the server side of the client/server, and as a result, the processor is used to run the threads of the application. If a large number of users access this application from client components, upgrading or adding an additional processor may improve performance. If an application is processor-bound, use the most powerful processor available.

Computers that are capable of symmetric multiprocessing allow use of multiple, though less powerful, processors instead of a single more powerful processor. Also, a mid-range processor may be used if fewer applications are used. Remember, when the processor becomes the bottleneck, additional processors can be added.

Disk Subsystem Implications

Client/server applications typically access large amounts of data, and therefore the demands on the disk subsystem are significant. Consider the disk controller and type of drive investments carefully.

Network Subsystem Implications

Client/server applications transfer many requests over the network for data access. These requests are often queries or commands that do not involve transferring large data files over the network, as in a file and print server environment. It is very important to get the data in and out of the server as quickly as possible.

Considerations When Forecasting in an Application Server Environment

There are several considerations you should think about when forecasting in an application server environment.

If Applications are Disk-Bound

If the applications are disk-bound, that is, they generate a large amount of data, and make a large number of requests on the disk, monitor the disk subsystem use.

If the disk subsystem is identified as the bottleneck and the application is predominantly reading from the disk subsystem, then a hardware retrieval and information database (RAID) implementation and disk or controller caching will provide performance improvement. If multiple drives are necessary, the addition of another controller can improve performance.

If the disk subsystem is identified as the bottleneck and the application is mainly writing to the disk, then a hardware RAID implementation will improve performance. If the application and data is critical, and fault tolerance is important, such as in a SQL Server environment, then a RAID 5 implementation is recommended. With RAID 5 implementations, the performance gain is less noticeable due to the process of writing parity information to achieve fault tolerance. If fault tolerance is not important, as in the case of loading application software from the server, then a RAID 0 implementation is beneficial to improve performance as data is spread over multiple physical hard disks.

If Applications are Memory-Intensive

If the applications are memory intensive, then monitor the memory counters as discussed in Module 1.

If memory is determined to be the bottleneck, add additional RAM or increase internal cache. One common problem is having too small of a secondary cache. The processor uses the secondary cache to provide read-ahead access to RAM. If RAM has been added, but the secondary cache size has not increased, this situation can result in lower cache usage, as the secondary cache must attempt to provide caching for a larger memory space. General recommendations for secondary cache sizes are 256K for 16–32 MB of RAM, and 512K for systems with more than 32 MB of RAM.

Additionally, if memory is determined to be the bottleneck, you can offload other applications or services to other servers. Moving an entire application, such as SQL Server, to another server distributes the load on the current computer, and spreads requests between servers. Some applications, such as Microsoft Systems Management Server centralized management for distributed systems, allow specific components to be moved to helper servers to provide a more balanced usage of system hardware resources. It may also be possible to move system services, such as remote-access service (RAS), to another computer to offload processing requirements from a single computer.

If Applications are Network-Intensive

If the applications generate a high volume of network traffic, monitor the network subsystem use. To do this, use Performance Monitor objects and counters, such as Network Segment: % Network Utilization, or a network traffic analyzer. Network Monitor can be used to view overall network statistics, and to view network traffic as well as individual packets. If the network subsystem is determined to be the bottleneck, then:

• Upgrade the network subsystem, including network adapter cards, to better performing models. Upgrading to 32-bit network adapter cards is very beneficial to the server performance.

• Add additional network adapter cards to distribute the load.

• Isolate traffic to specific segments by subnetting the network.

• Upgrade the network components, such as cabling and bridges, to higher performance components.

If Applications are CPU-Bound

If the applications are CPU-bound, monitor the processor usage. If the processor is determined to be the bottleneck and the application is multithreaded, or multiple applications and services are run simultaneously, then consider adding multiple processors in a symmetric multiprocessing computer.

If the processor is determined to be the bottleneck and the application is single-threaded, or very few other applications and services are running, then consider upgrading the processor in a single processor computer.

Calculating the Number of Users an Application Server Can Support

A question that system analysts are often asked is how many users can a specific server support? The answer to this question depends on many factors including the hardware configuration of the server, the type of applications the server is running, and what server resources these applications require.

To calculate the number of users that a particular server can support

1. Test a single user making normal transactions on the server using the predominant, front-end application against the engine of the server.

2. Capture data using the appropriate counters relative to application servers as introduced in the "Performance Analysis" module. Be sure to use any application-specific counters that are available, such as those added by Microsoft SQL Server, in the analysis.

3. Multiply the resources required to complete the transaction by the number of proposed users. This will provide an idea of how much resource utilization it will require for all users to simultaneously access the application and its data.

   Note: Because application servers predominantly use all resources, it is necessary to project on all four resources: memory, processor, disk, and network.

If the analysis indicates that the existing server will not be able to accommodate the number of users and applications required, then either an improvement in the appropriate resource is required, or the addition of another server to distribute the load is necessary.

Analysis in the Domain Server Environment

A domain server is a server that generates data transfer between itself and other servers, generally without the initiation of the data transfer occurring as the result of a user request. For example, a primary domain controller synchronizes the accounts database with backup domain controllers; likewise, a Windows® Internet Naming Service (WINS) Server replicates its database with its replication partner. Domain servers also validate user logon requests.

The analysis of a domain server largely focuses on different workload units, as the access of a domain server is different from a file and print server or an application server. A domain server, such as a domain controller, is accessed infrequently by users, but it generates activity that is not the direct result of user interaction, such as the synchronization of the domain accounts database.

The following table lists common workload units for a domain server and the respective Performance Monitor counter for each workload unit.

Workload unit	Performance Monitor counter
Concurrent logons	Server: Logon/sec
Invalid logon requests (Microsoft Windows NT client computers only)	Server: Error Logon
Total logon attempts since system startup	Server: Logon Total
Memory use	Memory: Available Bytes Memory: Committed Bytes
Network use	Network Segment: % Network Utilization
NetBIOS name service registrations	WINS Server: Total Number of Registrations/sec
NetBIOS name queries	WINS Server: Queries/sec

Resource Implications in the Domain Server Environment

A domain server environment involves communications between servers that are not initiated by client activity, such as domain controllers synchronizing the domain accounts database. When monitoring a domain server environment, system resources are used by the operating system and they need to be accounted for before planning for user access. Windows NT Server services such as NetLogon, WINS, and the Directory Replicator can all transfer data between servers on the network, without a user initiating the transfer. Properly determining the amount of data transferred by the operating system is crucial to determining resource availability for users.

Memory Implications

Each of the domain server transfers will consume some memory for the data transfer. Monitor memory counters to determine the affect that data transfers have on memory. Each service running requires additional RAM. For domain controllers, it is recommended to have RAM in the amount of 2.5 times the size of the Security Accounts Manager (SAM) database.

Processor Implications

All data transfers use processor cycles: this includes domain accounts database synchronization, WINS database replication, and data replication. During data transfer, fewer processor cycles are available for network access demands from users. Installing an additional processor helps in these environments.

Disk Subsystem Implications

Disk subsystem use is the same as a file and print server, although during internal data transfer times, disk responsiveness for users is affected.

Network Subsystem Implications

Domain account synchronization will take, on average, 1K per change if multiple changes are propagated, and as much as 4K for a single change. If large numbers of changes are to be synchronized, the synchronization can consume large percentages of wide area network (WAN) links. The default amount of network bandwidth that Windows NT uses for account synchronization is set to 100 percent of available bandwidth. For example, on a 56K point-to-point circuit, it could take about 24 hours to replicate a 30,000 user SAM. Perform as few full synchronizations of the domain accounts database as possible—instead perform partial synchronizations.

Considerations When Forecasting in a Domain Server Environment

When forecasting in a domain server environment, the analysis process is slightly different, because of the fact that more activity is created that is not the result of direct user interaction. Following is a list of common activities that will affect system resources without user intervention:

• Domain account synchronization.

• WINS database replication.

• Internet protocol (IP) address leases and renewals by means of dynamic host configuration protocol (DHCP).

• Browser updates.

• Systems Management Server verification and updates on logon servers.

The first two items in the previous bulleted list, domain account synchronization and WINS database replication, can cause a significant impact on system performance. The others, although they generate some activity, have significantly less impact on performance.

Two of the most common requests about domain server environments are how many users can simultaneously log on, and how many domain controllers are required given a specific number of users. Simultaneous logons are hardware independent. One domain controller is suggested for every 2,000 users to perform logon validation.

The following is a strategy to use when analyzing the affects of Windows NT Server communications:

• Monitor during the domain account synchronization process to determine the affect this has on memory, processor, disk, and network resources. Using Server Manager, synchronization can be forced, either with a specific server (initiating the request from a backup domain controller) to view the effect of a single synchronization, or from the primary domain controller to view the effect of synchronizing with all domain controllers.

• Monitor during the WINS server replication process. Using WINS Manager, the administrator can initiate the replication process manually when little other activity is occurring on the server. This helps to isolate the effect on the server during the replication process.

• Monitor the effect on the network and server when a single client attempts to log on and be validated. Determining the effects that a single user has on the network is easily projected into the effect on the server or servers, should all users attempt to log on at the same time.

Calculating the Number of Users a Domain Server Can Support

The recommendation for the number of users in a domain is dependent on the following:

• The maximum number of objects in the SAM is 40,000. The makeup of users, groups, and computer accounts does not matter, although:

  • Each user takes 1K of disk space.

  • Each local or global group takes 512 bytes and fifty bytes per member.

  • Each computer account takes 0.5K of disk space.

• The maximum size of the directory database is 40 MB. The SAM is the largest of the three items that make up the directory database. The SAM is also a part of the registry, and the total registry is limited to 108 MB.

Note: The processor type is relatively unimportant in relation to the number of users supported on a domain controller. Processor type is more important when considering client authentication, and when domain controllers are used for more than one purpose. For large domain operations, do not use the domain controller for anything other than normal domain controller activities, such as validating user logon requests and maintaining the user accounts database.

Proposing Solutions

When determining the expected response time, given a specific set of transactions, it is possible to encounter a situation where the numbers do not agree with the anticipated outcome. The current response time, for example, may be much slower than expected given a certain system environment. In this case, if everything seems to be okay and no problems exist in the system, a number of responses may be possible in the situation:

• Adjust the expectations to be more in line with what is currently being experienced.

• Reallocate resources (applications, services, or users) to other systems currently in the network.

• Expand the current resource that is overconsumed (acting as the system bottleneck).

• Purchase additional systems and then distribute the access load.

• Verify configuration settings.

The appropriate response to a particular situation varies with each scenario. Proper analysis, not only of the system in question, but also in conjunction with the current business plan, helps to dictate the appropriate solution to the problem.

Configuration Settings

If, after monitoring Windows NT Server, the server is not responding as expected, verify the configuration setting.

To configure the server service for a particular type of server, use the Server option under Services in the Network program in Control Panel.

• For an application server, click Maximize Throughput for Network Applications.

• For a file and print server, click Maximize Throughput for File Sharing.

• For a domain server, click Maximize Throughput for Network Applications.

Following are the options, and a description of each of the options, on the Server menu:

Option	Description
Minimize Memory Used	For use with up to ten simultaneous connections from client computers. This option is useful for a server that has a user running desktop applications locally.
Balance	For use with up to 64 simultaneous connections.
Maximize Throughput for File Sharing	For use with large number of clients in a file and print server environment.
Maximize Throughput for Network Applications	For use in an application server environment.

Note: For more information about server analysis and optimization, see "Additional Readings" under "Resources" on the course Web page.

© 1997 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.

Microsoft, FoxPro, Windows, and Windows NT are registered trademarks and SQL Server is a trademark of Microsoft Corporation.

Other product or company names mentioned herein may be the trademarks of their respective owners.