C#应用性能优化实战指南：深度剖析与提升策略

5星 · 超过95%的资源需积分: 13 189 浏览量更新于2024-07-27 2 收藏 8.12MB PDF 举报

"Apress.Pro.NET.Performance.Optimize.Your.C#.Applications"是一本专为.NET开发者设计的专业书籍，旨在帮助读者提升C#应用程序的性能，从而在竞争激烈的市场环境中保持优势。本书深入探讨了Windows、CLR（Common Language Runtime）以及硬件如何影响应用性能，并提供了实用的工具和技术来衡量代码在不受外部因素干扰下的表现。书中的主要内容包括： 1. **性能指标与测量**：首先介绍如何识别关键性能指标，然后通过多种性能分析器和其他工具指导读者进行精确的性能测量，以便了解程序瓶颈所在。 2. **类型内部原理**：详细解释.NET类型系统的工作方式，这对理解代码执行效率至关重要，尤其是对于内存管理和CPU利用率的影响。 3. **垃圾回收管理**：讲解如何有效管理内存，避免内存泄漏，通过与垃圾收集器的交互实现内存的高效利用。 4. **抽象选择与陷阱避免**：提供避免常见性能陷阱的策略，教导读者如何根据应用场景选择正确的抽象层，减少不必要的性能消耗。 5. **操作系统与运行时影响**：揭示操作系统和运行时对应用性能的隐性影响，帮助开发者理解底层技术对性能的制约和潜在优化空间。 6. **并行处理与优化**：探讨并行编程和并发技术，如任务并行库（TPL），以提升多核处理器上的性能。 7. **集合与泛型**：讨论如何通过优化数据结构和算法来减少I/O操作，提高数据访问速度。 8. **网络、I/O与序列化**：讲解网络通信、文件I/O和序列化过程中的性能优化技巧。 9. **不安全代码与互操作性**：讨论使用.unsafe代码区域进行性能优化以及与其他语言的交互策略。 10. **算法优化**：提供针对特定问题的算法优化方法，确保代码执行效率。 11. **性能模式**：总结实用的性能优化模式和最佳实践，帮助读者设计出高效的软件架构。 12. **Web应用性能**：针对Web应用，重点介绍如何提升用户体验，优化HTTP请求、响应时间和负载均衡等方面。这本书为.NET开发者提供了一个全面的指南，涵盖了从基础性能分析到高级技术实践的所有方面，旨在彻底改变读者对.NET应用开发性能的认识，使其能够开发出既高效又易于维护的应用程序。

CHAPTER 2 ■ PERFORMANCE MEASUREMENT

cONFIGUrING perFOrMaNce cOUNter LOGS

To configure performance counter logs, open Performance Monitor and perform the following steps. (We

assume that you are using Performance Monitor on Windows 7 or Windows Server 2008 R2; in prior

operating system versions, Performance Monitor had a slightly different user interface—if you are using

these versions, consult the documentation for detailed instructions.)

1. In the tree on the left, expand the Data Collector Sets node.

2. Right-click the User Defined node and select New ➤ Data Collector Set from the

context menu.

3. Name your data collector set, select the “Create manually (Advanced)” radio button,

and click Next.

4. Make sure the “Create data logs” radio button is selected, check the “Performance

counter” checkbox, and click Next.

5. Use the Add button to add performance counters (the standard Add Counters dialog

will open). When you’re done, configure a sample interval (the default is to sample

the counters every 15 seconds) and click Next.

6. Provide a directory which Performance Monitor will use to store your counter logs

and then click Next.

7. Select the “Open properties for this data collector set” radio button and click Finish.

8. Use the various tabs to further configure your data collector set—you can define a

schedule for it to run automatically, a stop condition (e.g. after collecting more than

a certain amount of data), and a task to run when the data collection stops (e.g. to

upload the results to a centralized location). When you’re done, click OK.

9. Click the User Defined node, right-click your data collector set in the main pane,

and select Start from the context menu.

10. Your counter log is now running and collecting data to the directory you’ve selected.

You can stop the data collector set at any time by right-clicking it and selecting

Stop from the context menu.

When you’re done collecting the data and want to inspect it using the Performance Monitor, perform the

following steps:

11. Select the User Defined node.

12. Right-click your data collector set and select Latest Report from the context menu.

13. In the resulting window, you can add or delete counters from the list of counters

in the log, configure a time range and change the data scale by right-clicking the

graph and selecting Properties from the context menu.

Finally, to analyze log data on another machine, you should copy the log directory to that machine, open

the Performance Monitor node, and click the second toolbar button from the left (or Ctrl + L). In the resulting

dialog you can select the “Log files” checkbox and add log files using the Add button.

CHAPTER 2 ■ PERFORMANCE MEASUREMENT

Custom Performance Counters

Although Performance Monitor is an extremely useful tool, you can read performance counters from any .NET

application using the System.Diagnostics.PerformanceCounter class. Even better, you can create your own

performance counters and add them to the vast set of data available for performance investigation.

Below are some scenarios in which you should consider exporting performance counter categories:

You are developing an infrastructure library to be used as part of large systems. Your •

library can report performance information through performance counters, which

is often easier on developers and system administrators than following log files or

debugging at the source code level.

You are developing a server system which accepts custom requests, processes them, •

and delivers responses (custom Web server, Web service, etc.). You should report

performance information for the request processing rate, errors encountered, and similar

statistics. (See the ASP.NET performance counter categories for some ideas.)

You are developing a high-reliability Windows service that runs unattended and •

communicates with custom hardware. Your service can report the health of the hardware,

the rate of your software’s interactions with it, and similar statistics.

The following code is all it takes to export a single-instance performance counter category from your

application and to update these counters periodically. It assumes that the AttendanceSystem class has

information on the number of employees currently signed in, and that you want to expose this information as a

performance counter. (You will need the System.Diagnostics namespace to compile this code fragment.)

public static void CreateCategory() {

if (PerformanceCounterCategory.Exists("Attendance")) {

PerformanceCounterCategory.Delete("Attendance");

}

CounterCreationDataCollection counters = new CounterCreationDataCollection();

CounterCreationData employeesAtWork = new CounterCreationData(

"# Employees at Work", "The number of employees currently checked in.",

PerformanceCounterType.NumberOfItems32);

PerformanceCounterCategory.Create(

"Attendance", "Attendance information for Litware, Inc.",

PerformanceCounterCategoryType.SingleInstance, counters);

}

public static void StartUpdatingCounters() {

PerformanceCounter employeesAtWork = new PerformanceCounter(

"Attendance", "# Employees at Work", readOnly: false);

updateTimer = new Timer(_ = > {

employeesAtWork.RawValue = AttendanceSystem.Current.EmployeeCount;

}, null, TimeSpan.Zero, TimeSpan.FromSeconds(1));

}

As we have seen, it takes very little effort to configure custom performance counters, and they can be of

utmost importance when carrying out a performance investigation. Correlating system performance counter

data with custom performance counters is often all a performance investigator needs to pinpoint the precise

cause of a performance or configuration issue.

CHAPTER 2 ■ PERFORMANCE MEASUREMENT

Note ■ Performance Monitor can be used to collect other types of information that have nothing to do with perfor-

mance counters. You can use it to collect configuration data from a system—the values of registry keys, WMI objects

properties, and even interesting disk files. You can also use it to capture data from ETW providers (which we discuss

next) for subsequent analysis. By using XML templates, system administrators can quickly apply data collector sets

to a system and generate a useful report with very few manual configuration steps.

Although performance counters offer a great amount of interesting performance information, they cannot

be used as a high-performance logging and monitoring framework. There are no system components that update

performance counters more often than a few times a second, and the Windows Performance Monitor won’t

read performance counters more often than once a second. If your performance investigation requires following

thousands of events per second, performance counters are not a good fit. We now turn our attention to Event

Tracing for Windows (ETW), which was designed for high-performance data collection and richer data types (not

just numbers).

Event Tracing for Windows (ETW)

Event Tracing for Windows (ETW) is a high-performance event logging framework built into Windows. As was

the case with performance counters, many system components and application frameworks, including the

Windows kernel and the CLR, define providers, which report events—information on the component’s inner

workings. Unlike performance counters, that are always on, ETW providers can be turned on and off at runtime

so that the performance overhead of transferring and collecting them is incurred only when they’re needed for a

performance investigation.

One of the richest sources of ETW information is the kernel provider, which reports events on process

and thread creation, DLL loading, memory allocation, network I/O, and stack trace accounting (also known as

sampling). Table 2-1 shows some of the useful information reported by the kernel and CLR ETW providers. You

can use ETW to investigate overall system behavior, such as what processes are consuming CPU time, to analyze

disk I/O and network I/O bottlenecks, to obtain garbage collection statistics and memory usage for managed

processes, and many other scenarios discussed later in this section.

ETW events are tagged with a precise time and can contain custom information, as well as an optional stack

trace of where they occurred. These stack traces can be used to further identify sources of performance and

correctness problems. For example, the CLR provider can report events at the start and end of every garbage

collection. Combined with precise call stacks, these events can be used to determine which parts of the program

are typically causing garbage collection. (For more information about garbage collection and its triggers, see

Chapter 4.)

CHAPTER 2 ■ PERFORMANCE MEASUREMENT

Accessing this highly detailed information requires an ETW collection tool and an application that can

read raw ETW events and perform some basic analysis. At the time of writing, there were two tools capable of

both tasks: Windows Performance Toolkit (WPT, also known as XPerf), which ships with the Windows SDK, and

PerfMonitor (do not confuse it with Windows Performance Monitor!), which is an open source project by the CLR

team at Microsoft.

Windows Performance Toolkit (WPT)

Windows Performance Toolkit (WPT) is a set of utilities for controlling ETW sessions, capturing ETW events into

log files, and processing them for later display. It can generate graphs and overlays of ETW events, summary

tables including call stack information and aggregation, and CSV files for automated processing. To download

WPT, download the Windows SDK Web installer from http://msdn.microsoft.com/en-us/performance/

cc752957.aspx and select only Common Utilities ➤ Windows Performance Toolkit from the installation options

screen. After the Windows SDK installer completes, navigate to the Redist\Windows Performance Toolkit

subdirectory of the SDK installation directory and run the installer file for your system’s architecture (Xperf_x86.

msi for 32-bit systems, Xperf_x64.msi for 64-bit systems).

Table 2-1. Partial List of ETW Events in Windows and the CLR

Provider Flag / Keyword Description Events (Partial List)

Kernel PROC_THREAD Creation and destruction of

processes and threads

Kernel LOADER Load and unload of images

(DLLs, drivers, EXEs)

Kernel SYSCALL System calls --

Kernel DISK_IO Disk I/O reads and writes

(including head location)

Kernel HARD_FAULTS Page faults that resulted in disk

I/O (not satisfied from memory)

Kernel PROFILE Sampling event—a stack trace

of all processors collected every

1ms

CLR GCKeyword Garbage collection statistics

and information

Collection started, collection

ended, finalizers run, ~100KB

of memory have been

allocated

CLR ContentionKeyword Threads contend for a managed

lock

Contention starts (a thread

begins waiting), contention

ends

CLR JITTracingKeyword Just in time compiler (JIT)

information

Method inlining succeeded,

method inlining failed

CLR ExceptionKeyword Exceptions that are thrown --

CHAPTER 2 ■ PERFORMANCE MEASUREMENT

Note ■ On 64-bit Windows, stack walking requires changing a registry setting that disables paging-out of

kernel code pages (for the Windows kernel itself and any drivers). This may increase the system’s working

set (RAM utilization) by a few megabytes. To change this setting, navigate to the registry key

HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management, set the

DisablePagingExecutive value to the DWORD 0x1, and restart the system.

The tools you’ll use for capturing and analyzing ETW traces are XPerf.exe and XPerfView.exe. Both tools

require administrative privileges to run. The XPerf.exe tool has several command line options that control which

providers are enabled during the trace, the size of the buffers used, the file name to which the events are flushed,

and many additional options. The XPerfView.exe tool analyzes and provides a graphical report of what the trace

file contains.

All traces can be augmented with call stacks, which often allow precise zooming-in on the performance

issues. However, you don’t have to capture events from a specific provider to obtain stack traces of what the

system is doing; the SysProfile kernel flag group enables collection of stack traces from all processors captured

at 1ms intervals. This is a rudimentary way of understanding what a busy system is doing at the method level.

(We’ll return to this mode in more detail when discussing sampling profilers later in this chapter.)

captUrING aND aNaLYZING KerNeL traceS WIth XperF

In this section, you’ll capture a kernel trace using XPerf.exe and analyze the results in the XPerfView.exe

graphical tool. This experiment is designed to be carried out on Windows Vista system or a later version.

(It also requires you to set two system environment variables. To do so, right click Computer, click Properties,

click “Advanced system settings” and finally click the “Environment Variables” button at the bottom of the

dialog.)

1. Set the system environment variable _NT_SYMBOL_PATH to point to the

Microsoft public symbol server and a local symbol cache, e.g.: srv*C:\Temp\

Symbols*http://msdl.microsoft.com/download/symbols

2. Set the system environment variable _NT_SYMCACHE_PATH to a local directory on

your disk—this should be a different directory from the local symbols cache in the

previous step.

3. Open an administrator Command Prompt window and navigate to the installation

directory where you installed WPT (e.g. C:\Program Files\Windows Kits\8.0\

Windows Performance Toolkit

4. Begin a trace with the Base kernel provider group, which contains the PROC_

THREAD

, LOADER, DISK_IO, HARD_FAULTS, PROFILE, MEMINFO, and MEMINFO_WS

kernel flags (see Table 2-1). To do this, run the following command: xperf -on

Base

5. Initiate some system activity: run applications, switch between windows, open

files—for at least a few seconds. (These are the events that will enter the trace.)

6. Stop the trace and flush the trace to a log file by running the following command:

xperf -d KernelTrace.etl

剩余360页未读，继续阅读

DoomLord

粉丝: 114
资源: 1318

C#应用性能优化实战指南：深度剖析与提升策略

Maximizing NET Performance

Pro .NET Performance 无水印pdf

Pro .NET Performance.pdf

Apress.Pro.NET.Best.Practices

高清彩版 Apress.Pro.NET.Memory.Management

Apress.Pro.Dynamic.NET.4.0.Applications.Jan.2010

Apress.Pro.Dynamic.dot.NET.4.0.Applications.Jan.2010

Apress.Pro.C#.2008.and.the.NET3.5.Platform

Apress.Developing.NET.Enterprise.Applications

Apress.Pro.C#.and.the.NET.4.5.Framework.6th.Edition

最新资源