构建高性能的ASP.NET应用（二）-性能优化演绎法

在上一篇文章中我们已经强调了思考力的重要性，因为思考力就决定了后续的行动。很多的时候在构建一个高性能应用的时候，我们要知道如何去提高应用程序的性能，换句话说，我们要知道从哪些方面去提升性能，我们更要知道：如果出现了性能问题，我们如何定位，解决。

大家可能会问：为什么本篇名称是“性能优化演绎法”。其实这是借用了破案推理中的一个概念，如果大家看过福尔摩斯，就知道我说的意思了。

在现实项目中，其实我们遇到更多的就是“调优“：遇到性能问题，找出问题，将之解决，从而使得应用程序性能提升。很多的项目都是在事后进行补救，想办法提升性能，这也是我们常常面临的情况。

很多的时候，性能问题往往不是表面看到的那么简单，因为很多的因素交织在一起，导致了性能问题。但是不管怎么样，“事实只有一个“，也就是导致性能出问题的一定有一个最终的”罪魁祸首“。例如，如果我们看到服务器CPU居高不下，此时如果我们认为就是CPU问题，急急忙忙的去换更好的CPU，这个操作可能就错了，因为导致CPU居高的因素有N多个，例如，内存不足就会导致CPU老高，因为CPU需要把原本保存在内存中的数据现在保存在磁盘的页上面，这样就严重的加大的CPU的调度和读写磁盘的频率，导致CPU飙高。原本只是需要加个内存的问题，最后导致我们换了CPU。可能这个内存问题还不是最终的问题，可能是程序中的某些地方没有合理的使用内存，例如，没有按需获取数据，而是每次都获取N多多余的不用的数据等到。

所以，调优就是一个抽丝剥茧的过程，需要不断的推理，然后进行下一步。

同时调优也是一个不断迭代的过程。当我们把一个最大的” 罪魁祸首“解决了之后，那么可能还有另外一个原本是小的” 罪魁祸首“现在成为了最大的” 罪魁祸首”。这么说可能大家有点晕，举个通俗的例子就是，把黑帮的老大干掉了，那么原本的老二就成为了老大，此时，我们必须把这个老二也干掉…，然后一直到最后上台的那个黑帮老大已经对我们没有什么威胁，我们就可以停止了。

性能优化就好比上面的“干掉黑帮老大”的过程，我们不可能把黑帮全部干掉，因为总会有漏网之鱼的，而且“黑白全在一念之间”，如果真的要彻底的干掉，那么成本太大，只要他们不捅出大篓子，可以容忍一下。在性能优化的时候，就是这样的：我们不断的解决遇到的明显的、影响了系统业务正常运转的性能瓶颈就行了。因为性能优化是一个永无止境的过程，没有最优，只有更优。

在进行构建高性能的应用或者调优的过程中，一定要有一个基准，就是要知道：何时该停止。

一般而言，性能的基准是根据业务而定的，不同的应用，其性能指标不同；甚至同一个应用，不同的时期性能指标也不同，而且同一个应用，不同的功能模块之间的性能指标又不一样：

要知道如何构建高性能的.NET应用，首先就要知道如何调优。为什么？ 好比，如果你要成为一个安全方面的专家，那么首先，你就得要是一个非常厉害的黑客，或者说，你要知道黑客的很多东西，因为只有知己知彼，你才能更好的防守。同理，如果我们要构建一个高性能的应用，首先，我们就要知道，可能会出现那些性能问题，如果出现了性能问题，我们如何快速而准确的去找到性能瓶颈，然后解决它。 应用中的性能问题，我们通过分析，找出瓶颈，然后我们就可以知道：哪些性能问题是如何产生的，我们就会在之后的项目设计中避开这些产生性能问题的地方。 如果说把“构建高性能应用“是一个正向推理，那么”精准的定位性能问题“就是一个逆过程。 从这里就可以知道： 构建高性能应用是个脑力活，不是搞几台设备，买几个软件就完事了的，如果没有找到性能瓶颈，上再多的设备也是枉然，只能暂时的缓解，但是问题还是会出来，而且会随着设备的变多而放大。 构建高性能应用需要比较强的思维能力，要具备正推与反推的能力。 构建高性能的应用需要对知识的掌握更加的深，而且也需要一定的广度。