構建高效能的ASP.NET應用（二）-效能最佳化演繹法

構建高效能的ASP.NET應用（二）-效能最佳化演繹法

 

在上一篇文章中我們已經強調了思考力的重要性，因為思考力就決定了後續的行動。很多的時候在構建一個高效能應用的時候，我們要知道如何去提高應用程式的效能，換句話說，我們要知道從哪些方面去提升效能，我們更要知道：如果出現了效能問題，我們如何定位，解決。

 

大家可能會問：為什麼本篇名稱是“效能最佳化演繹法”。其實這是借用了破案推理中的一個概念，如果大家看過福爾摩斯，就知道我說的意思了。

20130307021415.png(20.97 K)2013/3/8 11:21:31

 

 

在現實項目中，其實我們遇到更多的就是“調優“：遇到效能問題，找出問題，將之解決，從而使得應用程式效能提升。很多的項目都是在事後進行補救，想辦法提升效能，這也是我們常常面臨的情況。

 

很多的時候，效能問題往往不是表面看到的那麼簡單，因為很多的因素交織在一起，導致了效能問題。但是不管怎麼樣，“事實只有一個“，也就是導致效能出問題的一定有一個最終的”罪魁禍首“。例如，如果我們看到伺服器CPU居高不下，此時如果我們認為就是CPU問題，急急忙忙的去換更好的CPU，這個操作可能就錯了，因為導致CPU居高的因素有N多個，例如，記憶體不足就會導致CPU老高，因為CPU需要把原本儲存在記憶體中的資料現在儲存在磁碟的頁上面，這樣就嚴重的加大的CPU的調度和讀寫磁碟的頻率，導致CPU飆高。原本只是需要加個記憶體的問題，最後導致我們換了CPU。可能這個記憶體問題還不是最終的問題，可能是程式中的某些地方沒有合理的使用記憶體，例如，沒有按需擷取資料，而是每次都擷取N多多餘的不用的資料等到。

 

 

所以，調優就是一個抽絲剝繭的過程，需要不斷的推理，然後進行下一步。

 

 同時調優也是一個不斷迭代的過程。當我們把一個最大的” 罪魁禍首“解決了之後，那麼可能還有另外一個原本是小的” 罪魁禍首“現在成為了最大的” 罪魁禍首”。這麼說可能大家有點暈，舉個通俗的例子就是，把黑幫的老大幹掉了，那麼原本的老二就成為了老大，此時，我們必須把這個老二也幹掉…，然後一直到最後上台的那個黑幫老大已經對我們沒有什麼威脅，我們就可以停止了。

效能最佳化就好比上面的“幹掉黑幫老大”的過程，我們不可能把黑幫全部幹掉，因為總會有漏網之魚的，而且“黑白全在一念之間”，如果真的要徹底的幹掉，那麼成本太大，只要他們不捅出大簍子，可以容忍一下。在效能最佳化的時候，就是這樣的：我們不斷的解決遇到的明顯的、影響了系統業務正常運轉的效能瓶頸就行了。因為效能最佳化是一個永無止境的過程，沒有最優，只有更優。

在進行構建高效能的應用或者調優的過程中，一定要有一個基準，就是要知道：何時該停止。

一般而言，效能的基準是根據業務而定的，不同的應用，其效能指標不同；甚至同一個應用，不同的時期效能指標也不同，而且同一個應用，不同的功能模組之間的效能指標又不一樣：

 

 

  要知道如何構建高效能的.NET應用，首先就要知道如何調優。為什嗎？

好比，如果你要成為一個安全方面的專家，那麼首先，你就得要是一個非常厲害的駭客，或者說，你要知道駭客的很多東西，因為只有知己知彼，你才能更好的防守。同理，如果我們要構建一個高效能的應用，首先，我們就要知道，可能會出現那些效能問題，如果出現了效能問題，我們如何快速而準確的去找到效能瓶頸，然後解決它。

應用中的效能問題，我們通過分析，找出瓶頸，然後我們就可以知道：哪些效能問題是如何產生的，我們就會在之後的項目設計中避開這些產生效能問題的地方。

如果說把“構建高效能應用“是一個正向推理，那麼”精準的定位效能問題“就是一個逆過程。

從這裡就可以知道：

• 構建高效能應用是個腦力活，不是搞幾台裝置，買幾個軟體就完事了的，如果沒有找到效能瓶頸，上再多的裝置也是枉然，只能暫時的緩解，但是問題還是會出來，而且會隨著裝置的變多而放大。
• 構建高效能應用需要比較強的思維能力，要具備正推與反推的能力。
• 構建高效能的應用需要對知識的掌握更加的深，而且也需要一定的廣度。

 

更多：

構建高效能的ASP.NET應用（一）-先把思路搞對，然後對症下藥

構建高效能的ASP.NET應用（三）-從監控出發，讓一切用資料說話

構建高效能的ASP.NET應用（四）-效能的最佳化的目標