选择什么来衡量

在搜集数据测试数据前，你需要知道你要以怎样的指标来衡量测试结果。这听起来很容易，但实际上比你想象中的要难许多。如果你想降低内存使用量，你会选择什么方式呢？

• 私有工作集（Private working set）

• 提交大小（Commit size）

• 内存页（Paged pool）

• 峰值大小（Peak working set）

• 内存堆大小（.NET heap size）

• 大对象堆（Large object heap）
  and so on

为了追踪内存的使用情况，我们还需要记录一个小时内的平均值和峰值？内存与处理器进程负载的关系？正如你所看到的，随便就能举出十几个甚至更多与内存相关的性能指标。

我们需要尽可能的准确描述要测试的东西

一旦你决定要测试某个产品，你需要为每个性能指标提出一个目标。在早期开发阶段，订立的目标可能不够准确，或者与实际情况不符。但重点是，不是说一定要达到一开始规划的目标，而是强迫你构建一套可以自动测试你说提出这些性能指标的体系结构。
你的目标应该是可量化的吗，你的程序目标也许是“快”，这个是一个不错的指标，但不是一个好的指标，因为“快”是一个很主观的因素，你没有一个明确的东西来表示你是否达到了快这个目标。你需要给目标定一个数字，并且这个数字是要可以测试出来的。

坏：“用户界面需要正常相应”
好：“任何操作不应该造成UI线程卡住超过20毫秒”

能量化还不够好，还需要有更具体的描述，例如下面说的内存指标

坏：“内存应小于1G”
好：“内存在 100次/秒的峰值查询情况下，内存使用不超过1G”

对于第二个例子，给出了一个具体的情景，要在这个情景下达成怎样的目标就是一个比较好的测试用例

另外一个重要的决定性因素，是你写的应用的目标是什么。如果是以一个带GUI界面的引用，那么你需要必须保证任何时刻都能响应用户的操作请求。如果你写的是一个每秒处理几百几千访问的服务器程序，你的目标就算要保证I/O和CPU的利用率在一个很低的范围内。如果你设计的是一个与市面上不一样的服务器应用，那么从效率的角度上看，一旦你的架构除出问题（性能上的），在重新修改架构就非常麻烦了。

在设计新系统时，我们需要对性能指标做一些规划。这时你需要了解一些会对性能产生影响的地方，例如CPU，内存，IO的使用率等情况。举个栗子，如果你有一台16核，64G内存的机器以及10G的网络带宽，这时候你需要设定好一个阈值，如“每秒可以处理多少数据”，这个可以在一台机器无法满足需要时，你知道你还需要多少台机器。这些信息都是你在做规划时需要写在规划目标里的。

你可能听过 _Donald Knuth 说过的：“过早优化是万恶之源”。但这只适合代码级别的优化。你必须清楚你在设计上的缺陷会对应用产生多大的影响。你必须把性能目标考虑到设计中。你必须在一开始时就有一个明确的目标。性能和安全以及一些东西时不能事后设计，否则你会被架构重构教会你做人的道理。

性能分析（设计）放在项目的开始，比在写完代码后进入测试阶段再考虑性能，思路是不一样的。在项目开始前，你可以设计出达到你想要的在性能上的扩展性，而不会陷入一些架构陷阱里（我暂时没明白这里说的架构陷阱是指那些东西）。在进入项目的测试，部署和维护阶段，你才有更多的时间在代码层级的优化上，对热点函数代码做分析，减少cpu，内存的消耗。

最后，你需要了解Ahmdals定律(See [pdf]:http://www.writinghighperf.net/go/3)，特别是如何适用于顺序（序列化）编程以及选择哪个部分进行优化。在代码级别的优化堆整体性能用处不大，甚至会浪费时间。但你总是希望优化代码里效率最低的那部分。不过，聪明的你应该会知道，你不会有足够时间去干这件事情。这就是为什么你需要有一个好的性能监控系统（工具），否则，你甚至不知道从哪里改起。

原文地址：http://www.cnblogs.com/yahle/p/6267039.html
.NET社区新闻，深度好文，微信中搜索dotNET跨平台或扫描二维码关注