構建高性能的ASP.NET應用（二）-性能優化演繹法
在上一篇文章中我們已經強調了思考力的重要性，因為思考力就決定了后續的行動。很多的時候在構建一個高性能應用的時候，我們要知道如何去提高應用程序的性能，換句話說，我們要知道從哪些方面去提升性能，我們更要知道：如果出現了性能問題，我們如何定位，解決。
大家可能會問：為什么本篇名稱是“性能優化演繹法”。其實這是借用了破案推理中的一個概念，如果大家看過福爾摩斯，就知道我說的意思了。
在現實項目中，其實我們遇到更多的就是“調優“：遇到性能問題，找出問題，將之解決，從而使得應用程序性能提升。很多的項目都是在事后進行補救，想辦法提升性能，這也是我們常常面臨的情況。
很多的時候，性能問題往往不是表面看到的那么簡單，因為很多的因素交織在一起，導致了性能問題。但是不管怎么樣，“事實只有一個“，也就是導致性能出問題的一定有一個最終的”罪魁禍首“。例如，如果我們看到服務器CPU居高不下，此時如果我們認為就是CPU問題，急急忙忙的去換更好的CPU，這個操作可能就錯了，因為導致CPU居高的因素有N多個，例如，內存不足就會導致CPU老高，因為CPU需要把原本保存在內存中的數據現在保存在磁盤的頁上面，這樣就嚴重的加大的CPU的調度和讀寫磁盤的頻率，導致CPU飆高。原本只是需要加個內存的問題，最后導致我們換了CPU。可能這個內存問題還不是最終的問題，可能是程序中的某些地方沒有合理的使用內存，例如，沒有按需獲取數據，而是每次都獲取N多多余的不用的數據等到。
所以，調優就是一個抽絲剝繭的過程，需要不斷的推理，然后進行下一步。
同時調優也是一個不斷迭代的過程。當我們把一個最大的” 罪魁禍首“解決了之后，那么可能還有另外一個原本是小的” 罪魁禍首“現在成為了最大的” 罪魁禍首”。這么說可能大家有點暈，舉個通俗的例子就是，把黑幫的老大干掉了，那么原本的老二就成為了老大，此時，我們必須把這個老二也干掉…，然后一直到最后上台的那個黑幫老大已經對我們沒有什么威脅，我們就可以停止了。
性能優化就好比上面的“干掉黑幫老大”的過程，我們不可能把黑幫全部干掉，因為總會有漏網之魚的，而且“黑白全在一念之間”，如果真的要徹底的干掉，那么成本太大，只要他們不捅出大簍子，可以容忍一下。在性能優化的時候，就是這樣的：我們不斷的解決遇到的明顯的、影響了系統業務正常運轉的性能瓶頸就行了。因為性能優化是一個永無止境的過程，沒有最優，只有更優。
在進行構建高性能的應用或者調優的過程中，一定要有一個基准，就是要知道：何時該停止。
一般而言，性能的基准是根據業務而定的，不同的應用，其性能指標不同；甚至同一個應用，不同的時期性能指標也不同，而且同一個應用，不同的功能模塊之間的性能指標又不一樣：
