提升.NET高效编程：性能优化与CLR深度解析

需积分: 0 59 浏览量更新于2024-06-30 收藏 14.53MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源推荐

第

章性能评估及工具

1.1

选择评估内容



在收集性能数据之前，你需要知道评估的内容是什么。听上去这显而易见，但实际上涉

及面远比想象的要广泛得多。就拿内存来说，很显然需要评估内存的占用情况，以便减少内

存消耗。但要查看哪类内存呢？专用工作集内存（

PrivateWorkingSet

）、提交大小（

Commit 

Size

）、页面缓冲池（

PagedPool

）、峰值工作集（

PeakWorkingset

）、

.NET

堆内存大小，还

是大对象堆内存（

LargeObjectHe ap

，

LOH

）？为了保证负载的均衡，是否要查看各个处理

器的堆内存？是否还需要关心其他类型的内存？为了跟踪一段时间内的内存占用情况，是否

需要知道每小时的平均值和峰值？内存的占用是否和系统负载相关？现在你明白了吧，光是

针对内存，就能轻易地列出一大堆指标。而且目前我们还没有涉及私有堆内存（

Private

Heap

），也没有对程序本身进行评估，还不知道都是哪些对象正在消耗内存呢。



请尽可能明确地描述评估内容。



故事

我曾经负责过一个大型的服务程序，当时我把进程专有内存的大小作为关键的性能指标，根据

它来决定是否要在启动内存需求很高的大型任务之前重启进程。这导致了大量的

“

专有内存

”

被交换

出去，对降低系统的内存负载毫无意义，而我们真正的目标就是要降低内存的负载。我们后来修改

了评估系统，转而评估工作集内存，这才产生了效果，把内存占用量减少了几个 GB（我说过这是一

个大型应用）。



一旦确定了需要评估的内容，接下来就是选择每个指标的目标值。在开发阶段初期，这

些目标值可能比较易变，甚至不可能知道。其实在初始阶段不需要满足这些目标值，但这能

迫使你建立一套评价体系，依据这些值来自动评估你的工作。这些目标值应该是可量化的。

我们对程序的较高要求也许就是要“快”，当然这没错。但这不算是一个很好的指标，因为“快”

比较主观，没有什么明确的途径来判断是否达标。你必须能把目标定义成某个数字，而且是

可测量的数字。



差的目标：用户界面应该响应迅速。



好的目标：任何操作都不会阻塞

线程超过

20ms

。



但只是能被量化还不够，还需要十分精确，正如前面的内存优化案例中所述。



差的目标：内存占用应该小于

1GB

。



好的目标：当负载为每秒

100

个请求时，工作集内存的占用不能超过

1GB

。



第

章性能评估及工具

2

第二个版本的目标值给定了非常明确的前提条件，你可以明确知道是否满足需求。实际

上，这已给出了一个良好的测试用例。



目标值中的另一个决定因素是应用程序的类型。带有用户界面的程序必须不惜一切代价

保证

线程的响应能力，无论执行任何任务时都应如此。而服务器端程序每秒要处理几十、

几百，甚至几千个请求。它必须非常高效地完成

I/O

操作和数据同步，以保证吞吐量和

CPU

利用率的最大化。因此服务器端程序的设计完全不同于其他程序。如果某个应用程序的基础

架构先天不足，对效率问题考虑欠佳，那么再回头去修正就很难了。



在设计系统和规划性能评估方案时，有一条经验也许很有用，那就是设想一下理论上的

最佳性能。如果你能去掉其他所有开销，比如垃圾回收、

JIT

、线程中断，以及其他任何你能

想到的开销，然后还能剩下什么资源用来干活呢？对于负载、内存占用、

CPU

占用、内部同

步等资源，你能想到的理论极限是多少？这通常依赖于程序所处的硬件和操作系统。比如，

有

台

个处理器、

64GB

内存的服务器，带有

条

10GB

的网络，你需要估计一下最大并

行处理能力、内存中最多能存放多少数据，以及每秒的网络吞吐量是多少。这能帮助你作出

规划，假如

台服务器不够用，那到底需要多少台同档次的机器。所有这些信息都是性能评

估目标的绝佳来源。



你大概听说过一个说法：“过早的优化是万恶之源”，这是由

DonaldKn uth

首先提出的。

这句话仅适用于代码层面的微观优化。在设计阶段时，你需要理解整体架构和约束条件，不

然你就会遗漏一些关键点，这将严重制约程序的运行。你必须在设计阶段就把性能目标预先

考虑进去。



在软件设计阶段，就得考虑安全性等很多方面的问题。性能问题也一样，不能事后再议，

必须从一开始就提出明确的目标。要想从头开始把一个已有的应用程序重新设计一遍，这是

不可能的，这比一开始就考虑周全要付出多得多的代价。



在项目初始阶段的性能分析，与开发完成即将进入测试阶段的分析是不一样的。在初始

阶段必须得保证设计的灵活性，确保技术路线在理论上能完成任务，确保在架构上没有大的

问题以免除后患。一旦项目进入测试、部署和维护阶段，就得把更多的精力投入微观优化、

具体代码方式的分析、减少内存占用等工作。



最后，你还需要了解阿姆达尔定律（

Ahmdals’sLaw

，参见

http:/ /w ww.writi n ghi gh p erf . 

net/go/3 [PDF]

），特别是其应用于顺序执行程序的情况，以便能找到哪部分程序是需要优化

的。那些不能明显改善整体性能的微观优化，多半是在浪费时间。为了获得最佳效果，应该

优先优化那些效率最低的部分。优化永远不可能面面俱到，得有一个明智的起点。因此，准

备好优化目标，再有一套优秀的评估系统，这些都是十分重要的。不然你连从哪儿开始都不

知道。



1.2

平均值还是百分位值

3

1.2

平均值还是百分位值



在选择评估值时，需要考虑用什么统计值才合适。多数人会优先选用平均值。当然大部

分情况下这确实是个重要指标，但还应该考虑一下百分位值。如果对程序的可用性有要求，

肯定会用到百分比形式的性能指标。比如，“数据库请求的平均延迟必须少于

10ms

，

95%

以

上的数据库请求延迟必须少于

100ms

。”



你可能对这个概念不大熟悉，其实它相当简单。假定测了

100

次，并对结果排序，第

条结果就是本次结果数据的

95%

百分位值。

95%

百分位值的意思是：“采样数据中有

95%

的值

小于等于这个值。”



换句话说，“

的请求高于此值。”



对已排序数据集的第

个百分位值的计算公式为：

(P/100) × N

，这里

为百分位值，

为数据个数。



假定测得以下由

代垃圾回收导致的暂停服务时间（参见第

章），单位为毫秒（

，

已排序）：



、

。



这里有

个样本数据，平

均值为

17ms

，但

95%

百分位值远大于

50ms

。如果只看平均

值，你也许不会注意到垃圾回收引起的延时问题，但有了百分位值，判断就更加全面。你会

发现垃圾回收过程有时候的性能会很差。



这些数据还表示，中间值（

50%

百分位值）与平均值的差距相当大。那些占比高的数值，

对平均值的影响往往较大。



对于可用性要求很高的服务，百分位值通常要重要得多。可用性要求越高，需要跟踪评估的

百分位值就越高。一般

99%

就能满足需求了，但如果真的需要处理海量请求，

99.99%

、

99.999%

，

甚至更高的数值也是必要的。一般需要多高的百分位值，取决于业务需求而不是技术。



百分位值能让你了解到完整运行环境下性能指标的下降情况，因此它是很有价值的。即

使平均起来用户和请求的响应情况都还不错，但

90%

的百分位指标表示性能也许还有提升的

空间。这表示

10%

的操作受到了性能制约。通过对多个百分位值的跟踪，你就会知道这种性

能下降发生得有多快。这种用户和请求的响应百分位值到底有多重要，最终取决于业务需求，

这里确实存在“回报递减”（

Diminis hingReturns

）法则。要获得最后

的提升可能非常困

难，付出的代价也会极其高昂。



我说过，在上面的数据中

95%

百分位点是

50ms

。当然从技术上说，此例中的这个数值

毫无用处，因为样本数据太少，不具备统计学意义，也许这次只是偶发现象。可以用一条经

验法则来确定所需的样本数：比目标百分位值高

个数量级。对于

～

99%

至少需要

100

个

样本，对于

99.9%

至少需要

1000

个样本，对于

99.99%

则至少需要

10000

个样本，依此类推。

该法则在大部分情况下是有效的，但如果你想从数学角度了解到底需要多少样本数才够用，

第

章性能评估及工具

4

可以从

http://www.writinghighperf.net/go/4

开始学习。



1.3

评估工具



如果非要说出本书最重要的一条法则来，那就是：



评估、评估、再评估！

如果没有精确评估过，你是不会知道性能问题出在哪里。



你确实可以只靠查看代码或者直觉获得很多经验，也会获得一些哪里存在性能问题的强

烈暗示。你甚至会找对地方，但请彻底打消省略性能评估的念头，除非是些微不足道的问题。

原因有两个。



第一，假定你是对的，你确实精确地找到了性能问题所在。你也许想知道程序性能到底

提高了多少，对吧？有了扎实的数据作支撑，你的优化成就将会稳固很多。



第二，我不清楚出错的频率有多高。举个例子，有一次在分析本机进程内存和托管内存

时，我们一直认为性能问题是出在一个需要加载大量数据的地方。我们没有让开发人员设法

减少内存的占用，而是试着禁止加载组件。我们用调试器把进程的所有堆内存信息都做了转

储。让我们惊讶的是，大部分内存消耗都是由程序集的加载引起的，而不是因为数据太多。

由此我们省了不少力气。



如果缺少有效的评估工具，性能的优化就毫无意义。



性能的评估是一个持续性的过程，在使用开发工具、测试程序、监视工具时都应该穿插

进行。如果需要对程序的功能进行持续监测，那很可能就需要同时对性能进行监测。



本章接下来会讨论各种工具，用于配置、监视和调试性能问题。虽然我着重介绍的是免

费软件，但还有很多商业软件可用，有时它们能简化调优工作。如果你有购买这些工具软件

的预算，那就尽管去买吧。当然，使用我介绍的这些小工具（或是其他类似软件）还是很有

意义的。至少有一点，它们在客户的机器或生产环境中很容易运行。更重要的是，它们都是

“更贴近底层”（

ClosertotheMetal

）的小工具，能让你深入理解问题的本质，帮助你分析数

据，这些都是与使用什么工具无关的。



我会介绍每个工具软件的基本用法和常用背景知识。本书的各章中针对每个特定场景，

都会给出详细的操作步骤。你对界面及基本操作的熟练程度，决定了你的理解程度。



提示

在深入学习具体的工具软件之前，有一个用好它们的诀窍，那就是循序渐进。如果在一个大型

的、复杂的项目中尝试使用某个陌生的工具软件，不知所措、失败，甚至得到错误的结果，都是很

有可能发生的。如果要学习用一个新工具软件来评估性能，请创建一个测试程序，它实现的功能得

是众所周知的，然后用新工具来验证它的性能。这样，在更复杂的情形下，你就能更从容地使用这

个工具了，出现技术和判断错误的可能性也会更小。

剩余230页未读，继续阅读

亚赛大人

粉丝: 30
资源: 332

提升.NET高效编程：性能优化与CLR深度解析

.NET 高性能编程

构建高性能web1

.net c++ 代码规范

使用unity编写一段高性能socket代码

使用csharp编写一段高性能socket代码

python.net

directx与vb.net 视频播放

.net C# 会员验证代码

asp.net mvc 企业级实战 源代码

ado.net 封装方法

asp.net、c#面试题

.net跨平台有哪些

asp.net 4 高级编程 c#和vb.net (第4版)

.net和J2EE的比较

.net core开源商城

vs2022 .net7.0

dropzone.js asp.net core webapi 编写

.net/c#面试手册

ASP与ASP.NET比较

.net 百度人脸识别

最新资源

asp.net mvc 企业级实战源代码