构建高性能的ASP.NET应用（二）-性能优化演绎法
构建高性能的ASP.NET应用（二）-性能优化演绎法
在上一篇文章中我们已经强调了思考力的重要性，因为思考力就决定了后续的行动。很多的时候在构建一个高性能应用的时候，我们要知道如何去提高应用程序的性能，换句话说，我们要知道从哪些方面去提升性能，我们更要知道：如果出现了性能问题，我们如何定位，解决。
大家可能会问：为什么本篇名称是“性能优化演绎法”。其实这是借用了破案推理中的一个概念，如果大家看过福尔摩斯，就知道我说的意思了。
在现实项目中，其实我们遇到更多的就是“调优“：遇到性能问题，找出问题，将之解决，从而使得应用程序性能提升。很多的项目都是在事后进行补救，想办法提升性能，这也是我们常常面临的情况。
很多的时候，性能问题往往不是表面看到的那么简单，因为很多的因素交织在一起，导致了性能问题。但是不管怎么样，“事实只有一个“，也就是导致性能出问题的一定有一个最终的”罪魁祸首“。例如，如果我们看到服务器CPU居高不下，此时如果我们认为就是CPU问题，急急忙忙的去换更好的CPU，这个操作可能就错了，因为导致CPU居高的因素有N多个，例如，内存不足就会导致CPU老高，因为CPU需要把原本保存在内存中的数据现在保存在磁盘的页上面，这样就严重的加大的CPU的调度和读写磁盘的频率，导致CPU飙高。原本只是需要加个内存的问题，最后导致我们换了CPU。可能这个内存问题还不是最终的问题，可能是程序中的某些地方没有合理的使用内存，例如，没有按需获取数据，而是每次都获取N多多余的不用的数据等到。
所以，调优就是一个抽丝剥茧的过程，需要不断的推理，然后进行下一步。
同时调优也是一个不断迭代的过程。当我们把一个最大的” 罪魁祸首“解决了之后，那么可能还有另外一个原本是小的” 罪魁祸首“现在成为了最大的” 罪魁祸首”。这么说可能大家有点晕，举个通俗的例子就是，把黑帮的老大干掉了，那么原本的老二就成为了老大，此时，我们必须把这个老二也干掉…，然后一直到最后上台的那个黑帮老大已经对我们没有什么威胁，我们就可以停止了。
性能优化就好比上面的“干掉黑帮老大”的过程，我们不可能把黑帮全部干掉，因为总会有漏网之鱼的，而且“黑白全在一念之间”，如果真的要彻底的干掉，那么成本太大，只要他们不捅出大篓子，可以容忍一下。在性能优化的时候，就是这样的：我们不断的解决遇到的明显的、影响了系统业务正常运转的性能瓶颈就行了。因为性能优化是一个永无止境的过程，没有最优，只有更优。
在进行构建高性能的应用或者调优的过程中，一定要有一个基准，就是要知道：何时该停止。
一般而言，性能的基准是根据业务而定的，不同的应用，其性能指标不同；甚至同一个应用，不同的时期性能指标也不同，而且同一个应用，不同的功能模块之间的性能指标又不一样：
