You need to identify bottlenecks caused by poor design or implementation early in the application life cycle. Bottlenecks that cannot be optimized or tuned need to be identified as constraints during the design phase of the life cycle, so that they can be ctored in the design to minimize the impact on performance.

If the value of% Processor Timeis high, then queuing occurs, and in most scenarios the value ofSystem\Processor Queue Lengthwill also be high. Figure 17.6 shows a sample System Monitor graph that indicates a high percentage of processor time and a high processor queue length.

Figure 17.1: Performance tuning categories

Use Diskpar.exe on Windows 2000to reduce performance loss due to misaligned disk tracks and sectors. You can use get the Diskpar.exe from the Windows 2000 Resource Kit.

Avg. Disk sec/Transfer

Note   Processor utilization depends on your system and application characteristics. The 75% threshold value given in Bottlenecks (following) is based on typical observations. Increase or decrease this threshold based on your system characteristics.

A high value ofPages/secindicates that your application does not have sufficient memory. The average ofPages Input/secdivided by average ofPage Reads/secgives the number of pages per disk read. This value should not generally exceed five pages per second. A value greater than five pages per second indicates that the system is spending too much time paging and requires more memory (assuming that the application has been optimized). The System Monitor graph shown in Figure 17.8 is symptomatic of insufficient memory.

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Continuing with the example introduced earlier, if you are performing a remote database call, you can measure the time taken by the database call to complete. Monitor the metrics related to indexes, locks, number of tables scanned, resource utilization levels, and so forth on the database to identify the reason why the query is taking a long time to execute.

Application. Includes the application configuration parameters.For .NET applications, these parameters are primarily located in configuration files. ASP.NET applications use Web.config configuration files.

Memory

Tune the amount of memory allocated if you can control the allocation. For example, you can tune this for ASP.NET and SQL Server.

Use Chapter 15,Measuring .NET Application PerformanceBefore implementing the steps in the current chapter, make sure you have Chapter 15 available, because it provides details about the measurements that you need to identify bottleneck causes.

Processor% Processor Time% Privileged Time

patterns & practices Library

Memory consists of physical and virtual memory. You need to consider how much memory is allocated to your application. When you evaluate memory-related bottlenecks, consider unnecessary allocations, inefficient clean up, and inappropriate caching and state management mechanisms. To resolve memory-related bottlenecks, optimize your code to eliminate these issues and then tune the amount of memory allocated to your application. If you determine during tuning that memory contention and excessive paging are occurring, you may need to add more physical memory to the server.

Platform. Includes the host operating system and the .NET Framework, together with Web and database servers such as Internet Information Services (IIS) and Microsoft SQL Server™. The .NET Framework configuration is maintained in Machine.config. Settings in this file affect all of the .NET applications on the server.

Web Services Tuning

Figure 17.2: The performance tuning process

A low value ofAvailable MBytesindicates that your system is low on physical memory, caused either by system memory limitations or an application that is not releasing memory. Monitor each process objects working set counter. IfAvailable MBytesremains high even when the process is not active, it might indicate that the object is not releasing memory. Use the CLR Profiler tool at this point to identify the source of any memory allocation problems. For more information, see How To: Use CLR Profiler in the How To section of this guide.

The tuning process is an iterative processing that consists of the following set of activities.

Fix issues in a prioritized order. Address the issues that are likely to provide maximum payoff. For example, instead of fine-tuning ASP.NET, you might achieve better initial results by creating an index on a database table that you identified was missing.

Summary:This chapter provides an iterative process to systematically identify, tune, and eliminate bottlenecks until your application meets its performance objectives. The chapter covers tuning the ASP.NET thread pool for various scenarios, including burst load and COM interop . It also shows you how to tune timeouts such as session timeouts, script timeouts, execution timeout and deadlock intervals. It also explains how to tune Web gardens, the Enterprise Services object pool, and much more.

A bottleneck is the device or resource that constrains throughput. Most of the time, performance bottlenecks in your application relate to resource issues that may include server resources such as CPU, memory, disk I/O, and network I/O or other external resources such as available database connections or network bandwidth.

You should be able to identify and isolate the areas that need further tuning. This assumes that you have already optimized your code and design for any changes, and that only the configuration settings need tuning.

Analyze and tune the application that is causing the high CPU utilization. You can dump the running process by using the ADPLUS utility and analyze the cause by using Windbg. These utilities are part of the Windows debugging toolkit. You can download these tools from

For more information about using ACT, see How To: Use ACT to Test Performance and Scalability and How To: Use ACT to Test Web Services Performance in the How To section of this guide.

The data you collect is usually only an indicator of a problem and is not the source of the problem. Indicators such as performance counters can give you directions to help isolate your debugging or troubleshooting process to target specific areas of functionality.

Document your analysis. Write down your recommendations, including what you observed, where you observed it 考研论坛, and how you applied configuration changes to resolve the issue.

The performance counters shown in Table 17.2 help you identify memory bottlenecks. You should log these counter values to log files over a 24 hour period before you form any conclusions.

For all iterations of the tuning process, make sure that you use the same test scripts and a constant workload. Doing so enables you to accurately measure the impact of any configuration changes that you have applied.

To resolve disk-related bottlenecks:

You can monitor an individual process or use_Totalfor all instances. High rates of processor activity might indicate an excessively busy processor. A long, sustained processor queue is a more certain indicator of a processor bottleneck. If a single processor in a multi-processor server is overloaded, this might indicate that you have a single-threaded application using just that single processor.

Web/Application server. Some common causes of bottlenecks include inefficient session and state management, thread contention, long-running calls to a Web service or a database, and chatty inteces.

Distribute workload among multiple drives. Windows Clustering and Distributed File System provide solutions for load balancing on different drives.

Performance objectivesYour applications performance objectives are usually measured in terms of response times, throughput (requests per second), and resource utilization levels. They should include budgeted times for specific scenarios together with resource utilization levels such as CPU, memory, disk I/O, and network I/O allocated for your application. For more information about setting performance goals, see Performance Best Practices at a Glance in this guide.

As an example of how configuration changes can have a cascading effect, changing the thread pool settings on the Web server might cause requests to be processed ster, which may in turn causes increased resource utilization (CPU, memory, and disk I/O) on your database server.

Disable last access update.By deult, NTFS updates the date and time stamp of the last access on directories whenever it traverses the directory. For a large NTFS volume, this update process can slow performance. To disable automatic updating, create a new REG_DWORD registry entry namedNtfsDisableLastAccessUpdatein HKEY_LOCAL_MACHINE \SYSTEM\CurrentContolSet \Control \Filesystem and set its value to 1.

You should optimize the page file to improve the virtual memory performance of your server. The combination of physical memory and the page file is called the virtual memory of the system. When the system does not have enough physical memory to execute a process, it uses the page file on disk as an extended memory source. This approach slows performance. To ensure an optimized page file:

Add multiple processors if you have multi-threaded applications. Consider upgrading to a more powerful processor if your application is single-threaded.

When you measure throughput across user loads, watch for the peak levels of throughput. At the point where throughput starts to ll, the bottleneck has been hit. Performance continues to degrade from this point onward. An example is shown in Figure 17.4.

Increase the page file size on the system to 1.5 times the size of physical memory available, but only to a maximum of 4,095 MB. The page file needs to be at least the size of the physical memory to allow the memory to be written to the page file in the event of a system crash.

Disk I/O refers to the number of read and write operations performed by your application on a physical disk or multiple disks installed in your server. Common activities that can cause disk I/O – related bottlenecks include long-running file I/O operations, data encryption and decryption, reading unnecessary data from database tables, and a shortage of physical memory that leads to excessive paging activity. Slow hard disks are another ctor to consider.

When you measure response times with varying number of users, watch for a sharp rise in response time. This rise is the point of poor efficiency, and performance only degrades from this point onward, as shown in Figure 17.3.

Performance tuning is an iterative process. Having applied one set of changes, you retest and measure to see whether the configuration changes have been beneficial. Continue the process until your application meets its performance objectives or until you decide on an alternate course of action, such as code optimization or design changes.

For more information about how to measure these counters, their thresholds, and their significance, see Processor in Chapter 15, Measuring .NET Application Performance.

For more information about measuring throughput, load testing, and generating user load, see Chapter 15,Measuring .NET Application Performanceand Chapter 16,Testing .NET Application Performance

Remove unnecessary protocols and drivers. Even idle protocols use space in the paged and nonpaged memory pools. Drivers also consume memory, so you should remove unnecessary ones.

Use stripe sets to process I/O requests concurrently over multiple disks.The type you use depends on your data-integrity requirements. If your applications are read-intensive and require ult tolerance, consider a RAID 5 volume. Use mirrored volumes for ult tolerance and good I/O performance overall. If you do not require ult tolerance, implement stripe sets for st reading and writing and improved storage capacity. When stripe sets are used, disk utilization per disk should ll due to distribution of work across the volumes, and overall throughput should increase.If you find that there is no increased throughput when scaling to additional disks in a stripe set, your system might be experiencing a bottleneck due to contention between disks for the disk adapter. You might need to add an adapter to better distribute the load.

application server tuning Chapter 17 – Tuning .NET Application Performance,J.D. Meier, Srinath Vasireddy, Ashish Babbar, and Alex Mackman

If you determine that your application has memory issues, your options include adding more memory, stopping services that you do not require, and removing unnecessary protocols and drivers. Tuning considerations include:

For more information about how to measure these counters, their thresholds, and their significance, see Disk I/O in Chapter 15, Measuring .NET Application Performance.

The current chapter starts by explaining three performance-tuning categories: system, platform, and application. It then presents an iterative performance-tuning process and explains the significance of starting with a baseline set of metrics, applying a single set of configuration changes at a time, and testing and measuring to determine whether your changes have been successful.

Home Pagefor Improving .NET Application Performance and Scalability

System Tuning

Before you start to tune your application, you need to have an established baseline. You need to ensure that the following are well defined:

Network I/O

MemoryAvailable MBytesPage Reads/sec

Enterprise Services Tuning

Send feedbackto Scal/p>

Read Chapter 16,Testing .NET Application PerformanceRead Chapter 16 before reading the current chapter.

Pages/sec

These metrics help you identify whether you are moving toward or away from your performance goals with each iteration through the tuning process. These also give you a rough idea as to which resource is the first bottleneck for the application, and on which server the bottleneck occurs.

The next step is to identify which process is causing the spike (or consuming processor time.) Use Task Manager to identify which process is consuming high levels of CPU by looking at theCPUcolumn on theProcessespage. You can also determine this by monitoringProcess\%Processor Timeand selecting the processes you want to monitor. For example, from the System Monitor output shown in Figure 17.7, you can see that the ASP.NET worker processor is consuming a majority of the processor time.

CacheMDL Read Hits %For more information about how to measure these counters, their thresholds, and their significance, see Memory in CLR and Managed Code in Chapter 15, Measuring .NET Application Performance.

Test plans and test scriptsYou need a test plan and a set of test scripts that you can use to apply load to your application. For more information about how to approach testing, see Chapter 16, Testing .NET Application Performance.

Note   Although you can change the process priority level of an application by using Task Manager or from the command prompt, you should generally avoid doing so. For almost all cases, you should follow one of the recommendations in the previous list.

Analyze resource utilization levels across linearly increasing user loads. See whether the resource utilization levels increase at a sharper rate as new users are added and more transactions are performed. Figure 17.5 shows a linear utilization level for increased user load.

Microsoft Windows® 2000 retrieves programs and data from disk. The disk subsystem can be the most important aspect of I/O performance, but problems can be masked by other ctors, such as lack of memory. Performance console disk counters are available within both theLogicalDiskorPhysicalDiskobjects.

Disk I/O

Categories for Tuning

The performance counters shown in Table 17.1 help you identify processor bottlenecks.

Figure 17.7: System monitor output showing the ASP.NET worker process consuming over 98% of processor time

Use test tools such as Microsoft Application Center Test (ACT) to simulate load. You can use tools like System Monitor or Microsoft Operations Manager to capture performance counters.

If you run short duration tests, make sure you include an appropriate warm-up time in your test scripts to ensure that your results are not skewed due to initial slow response times caused by just-in-time (JIT) compilation, cache population, and so on. Also make sure to run your tests for an adequate and realistic period of time.

When you run tests for the first time, make sure you use the same version of the application that you used to establish your baseline metrics. For subsequent iterations of the tuning process, you test performance with the same workload and test scripts but with modified configuration changes.

If, during your analysis, you identify several bottlenecks or performance issues, prioritize them and address those that are likely to have the biggest impact first. You can also prioritize this list on the basis of which bottleneck you hit first when running a test.

In thapplication server tuningis step, you analyze the captured data to identify performance issues and bottlenecks. To identify the root cause of a problem, start tracing from where you first notice the symptom. Often, the most obvious observation is not the cause of the problem. When you analyze your data, bear in mind the following points:

Figure 17.6: System monitor graph showing high percentage of processor time and high processor queue length

Disk Writes/sec

If you observe a high rate of context switching, consider reducing the thread count for your process before increasing the number of processors.

Performance tuning is an iterative process that you use to identify and eliminate bottlenecks until your application meets its performance objectives. You start by establishing a baseline. Then you collect data, analyze the results, and make configuration changes based on the analysis. After each set of changes, you retest and measure to verify that your application has moved closer to its performance objectivapplication server tuning Chapter 17 – Tuning .NET Application Performancees. The purpose is not to load, stress, or capacity test your application, but to understand how the various tuning options and configuration settings affect your application. Figure 17.2 shows the basic tuning process.

The performance counters shown in Table 17.3 help you identify disk I/O bottlenecks.

Baseline metricsMake sure that you capture a baseline set of metrics for your system, platform, and application. Baseline metrics helps you evaluate the impact of any changes made to your configuration during the performance-tuning process. For more information about metrics, see Metrics in Chapter 16, Testing .NET Application Performance.

A typical test generates a vast amount of data in different locations, from different sources, and in different formats. For example, captured data includes system performance counters from all servers, IIS log files from Web and/or application servers, SQL Server metrics on the database server, and so on. You must collect the data together and format it in preparation for the next step, analyzing the results.

SystemProcessor Queue LengthContext Switches/sec

Table 17.1: Performance Counters Used to Identify CPU Bottlenecks

ServerPool Nonpaged FailuresPool Nonpaged Peak

Analyze the instrumentation log generated by your application and isolate the subsystem that is taking the maximum amount of time for execution, and check whether it actually needs a code review rather than just tuning the deployment.

Table 17.3: Performance Counters Used to Identify Disk I/O Bottlenecks

Identify whether your system has a shortage of physical memory, and, if so, add more memory to avoid excessive paging.

Caution   Some applications, such as incremental backup utilities, rely on the NTFS update information and cease to function properly without it.

Avg. Disk Write Queue Length

Avg. Disk sec/Read

Apply one set of changes at a time. Address changes individually. Making multiple configuration changes can distort the results and can make it difficult to identify potential new performance issues. A single change may actually include a set of multiple configuration changes that need to be applied and evaluated as a single unit.

Disable creation of short names. If you are not supporting MS-DOS for Windows 3.xclients, disable short names to improve performance. To disable short names, change the deult value of the \NtfsDisable8dot3NameCreationregistry entry (in HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Control \Filesystem) to 1.

Limit your use of file compression or encryption.File compression and encryption are I/O-intensive operations. You should only use them where absolutely necessary.

Table 17.2: Performance Counters Used to Identify Memory Bottlenecks

Cache Faults/sec

System. Includes the hardware resources on a server. These resources include CPU, memory, disk I/O, and network I/O.

Intermittent spikes in your data as shown by performance counters may not be a big concern. If it makes sense to, ignore anomalies.

CPU

Performance tuning refers to the identification and systematic elimination of bottlenecks to improve performance. The focus for tuning in this chapter is on configuration settings, and therefore this chapter is of interest to both administrators and developers. The chapter shows you how to identify bottlenecks, and then how to apply the relevant configuration changes to help eliminate them. Code optimization is the subject of the technology-specific chapters in Part III, Application Performance and Scalability of this guide.

Cache Bytes

Using input from the coarse-grained monitoring of your performance objectives mentioned earlier, you can add additional counters during subsequent iterations of the tuning process.

PhysicalDiskAvg. Disk Queue LengthAvg. Disk Read Queue Length

ADO.NET Tuning

If you are currently in the process of performance tuning, then you need to compare your current set of results with previous results or with your baseline performance metrics.

Read Chapter 4,Architecture and Design Review of a .NET Application for Performance and ScalabilityRead Chapter 4 to help identify potential bottlenecks caused by specific architecture or design decisions.

SQL Server Tuning

If the data you collect is not complete, then your analysis is likely to be inaccurate. You sometimes need to retest and collect the missing information or use further analysis tools. For example, if your analysis of Common Language Runtime (CLR) performance counters indicates that a large number of generation 2 garbage collections are occurring, then you should use the CLR Profiler tool to profile the overall memory usage pattern for the application.

Bottlenecks vary from layer to layer, based on the server role:

To save memory:

Additional Resources

Turn off services you do not use. Stopping services that you do not use regularly saves memory and improves system performance.

Subsequent sections of this chapter show you how to tune ASP.NET, Web services, Enterprise Services, and ADO.NET, and then how to tune shared system resources including CPU, memory, disk I/O, and network I/O. In each case, you are shown how to identify bottlenecks and how to eliminate them.

Internet Information Services (IIS) Tuning

How to Use This Chapter

Related Links

How well your applications, services, and operating system use shared system-level resources has a direct impact on throughput, queuing, and response time. Tools such as System Monitor enable you to monitor resource usage. You should monitor the following shared system components at a minimum:

Summary

Reserve appropriate space for the master file table. Add theNtfsMftZoneReservationentry to the registry as a REG

Bottleneck Identification

Separate the data files and the page file to different disks only if the disk is a bottleneck because of a lot of I/O operation. These files should preferably be on the same physical drive and the same logical partition. This keeps the data files and the page file physically close to each other and avoids the time spent seeking between two different logical drives.

Configuration and tuning settings can be divided into the following categories. These are the areas where you focus your tuning efforts:

Configure. Tune your application setup by applying new system, platform, or application configuration settings.

To determine the impact of excessive paging on disk activity, multiply the values of thePhysical Disk\ Avg. Disk sec/TransferandMemory\ Pages/seccounters. If the product of these counters exceeds 0.1, paging is taking more than 10 percent of disk access time. If this occurs over a long period, you probably need more memory. After upgrading your systems memory, measure and monitor again.

Establish a baseline. Ensure that you have a well defined set of performance objectives, test plans, and baseline metrics.

The first step in identifying bottlenecks is to know the different tests and measurements that you must run to simulate varying user loads and access patterns for the application. The following measurements help you to expose bottlenecks and isolate areas that require tuning:

Performance Tuning Process

Overview

Microsoft Corporation

Tuning involves proactively tuning deults across servers and then tuning for specific application scenarios, such as burst load conditions. This process might involve tuning configuration settings on specific servers and not across all servers. If you tune a configuration file specific to one server, and subsequently move that file to another server, you often need to retune. For example, tuning the thread pool in ASP.NET depends on the number of CPUs installed. If the configuration file is moved from a two-CPU server to a four-CPU server, then you must retune.

You can format the data in such a way that you are able to map the cascading effect of changes in one part of your configuration across your application. Organizing the data into the categories described earlier (system, platform, and application) helps you analyze the application as a whole, rather than analyzing it in parts.

Note   When attempting to analyze disk performance bottlenecks, you should always use physical disk counters. In Windows 2000, physical disk counters are enabled by deult, but logical disk counters are disabled by deult. If you use software RAID, you should enable logical disk counters by using the following command.

Read the technology chapters. Read the chapters in Part III, Application Performance and Scalability, to learn about how to optimize your code and avoid bottlenecks caused by poor coding practices.

For more information about the location and partitioning of the page file, see Knowledge Base article 197379, Configuring Page Files for Optimization and Recovery, at

Read Chapter 3,Design Guidelines for Application PerformanceRead Chapter 3 to help ensure that you do not introduce bottlenecks at design time.

Low memory leads to increased paging where pages of your applications virtual address space are written to and from disk. If paging becomes excessive, page thrashing occurs and intensive disk I/O decreases overall system performance.

Database server. Some common causes for bottlenecks include poor logical database design such as bad table design, improper normalization of tables, inefficient indexes on tables, and badly partitioned data across tables. Other causes include inefficient queries, inappropriate isolation levels used by transactions in queries, and inefficient stored procedures.

Objectives

CLR Tuning

Remoting Tuning

ASP.NET Tuning

.NET Framework Tuning

You tune your application setup by applying new system, platform, or application configuration settings. The analysis documentation from the previous step can contain several recommendations, so use the following guidelines when you apply configuration changes:

Make sure that your test results are not skewed by warm-up time. Make sure that your test scripts run for a period of time before you start capturing metrics.

Each application that runs on a server gets a time slice of the CPU. The CPU might be able to efficiently handle all of the processes running on the computer, or it might be overloaded. By examining processor activity and the activity of individual processes including thread creation, thread switching, context switching, and so on, you can gain good insight into processor workload and performance.

May 2004