.NET性能优化：提升C#应用效能

VS2013

5星 · 超过95%的资源需积分: 9 48 浏览量更新于2024-07-23 3 收藏 8.39MB PDF 举报

"Pro .Net Performance: Optimize Your C# Applications" 这本书是.NET应用程序性能优化的专业指南，专注于C#应用的性能提升。针对VS2013集成开发环境，本书详细探讨了性能优化的各种策略和技巧。作者们通过深入讲解性能指标、测量方法以及关键的.NET框架内部工作原理，帮助开发者提升代码效率。书中的章节涵盖了广泛的主题，包括： 1. **性能指标**：这一章介绍了衡量应用性能的关键指标，如响应时间、吞吐量、CPU利用率等，这些都是优化工作的基础。 2. **性能测量**：讲述了如何使用工具（如Visual Studio 2013内置的性能分析器）来准确地测量应用的性能，以便定位问题。 3. **类型内部结构**：深入到.NET类型系统内部，理解对象创建、内存分配以及类型布局对性能的影响。 4. **垃圾收集**：详细解析.NET的垃圾回收机制，包括不同代际的内存管理，以及如何减少GC停顿时间。 5. **集合与泛型**：探讨集合类的性能特性，以及泛型在优化代码可读性和性能上的作用。 6. **并发与并行性**：讨论多线程编程的最佳实践，如何有效地利用多核处理器提升并发性能。 7. **网络、I/O和序列化**：分析网络通信、文件操作和数据序列化过程中的性能瓶颈，并提供优化建议。 8. **不安全代码和互操作性**：介绍使用C#的unsafe关键字进行低级编程，以及与其他平台（如C++）交互时的性能考虑。 9. **算法优化**：讲解如何通过改进算法设计提高程序运行效率，包括数据结构选择和计算复杂度分析。 10. **性能模式**：探讨常见的性能优化模式，如缓存、预加载、异步处理等，以及如何在实际项目中应用。 11. **Web应用程序性能**：专门针对Web应用，讨论HTTP协议、页面渲染和数据库交互等环节的优化技术。最后，附有完整的索引，方便读者查找特定主题。本书不仅适合经验丰富的.NET开发者，也适合想要提升自己应用性能的初学者。通过阅读本书，开发者能够掌握识别和解决性能问题的全面知识，从而编写出更高效、更快的C#应用程序。

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.

www.it-ebooks.info

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.

www.it-ebooks.info

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.)

www.it-ebooks.info

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 --

www.it-ebooks.info

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

www.it-ebooks.info

剩余360页未读，继续阅读

imyourfather

粉丝: 1
资源: 2

.NET性能优化：提升C#应用效能

.NET开发性能优化 (英文版)

Pro .NET Performance 无水印pdf

Pro .NET Performance.pdf

ASP.NET Core: Cloud-ready, Enterprise Web Application Development

MCAD/MCSD Self-Paced Training Kit: Developing Windows-Based Applications with Microsoft Visual Basic .NET and Microsoft Visual C# .NET, Second Edition

Learning.NET.High.Performance.Programming

asp.net_Core_2_High_Performance_second_edition

[CSLA .NET] CSLA .NET 框架企业应用开发艺术 (2008 版本) (英文版)

Professional C# 3rd Edition

《#企业应用开发艺术CSLA.NET框架开发实战》配套源码及例程csla-4.5.700

最新资源