構建高效能ASP.NET網站 第五章—效能調優綜述(前篇)
前言:這段時間,把系列文章又重新整理了一下,之前關於效能最佳化的介紹一些不是很清晰。可以說從本篇開始,才算是一個完整的系列的開始。
系列文章連結:
構建高效能ASP.NET網站 開篇
構建高效能ASP.NET網站之一 剖析頁面的處理過程(前端)
構建高效能ASP.NET網站之二 最佳化HTTP請求(前端)
構建高效能ASP.NET網站之三 細節決定成敗
構建高效能ASP.NET網站 第五章—效能調優綜述(前篇)
大型高效能ASP.NET系統架構設計
構建高效能ASP.NET網站 第五章—效能調優綜述(中篇)
構建高效能ASP.NET網站 第五章—效能調優綜述(後篇)
構建高效能ASP.NET網站 第六章—效能瓶頸診斷與初步調優(上篇)—識別效能瓶頸
構建高效能ASP.NET網站 第六章—效能瓶頸診斷與初步調優(下前篇)—簡單的最佳化措施
構建高效能ASP.NET網站 第六章—效能瓶頸診斷與初步調優(下後篇)—減少不必要的請求
構建高效能ASP.NET網站 第七章 如何解決記憶體的問題(前篇)—託管資源最佳化—記憶體回收機制深度剖析
構建高效能ASP.NET網站 第七章 如何解決記憶體的問題(前中篇)—託管資源最佳化—監測CLR效能
本章的議題如下:
效能調優的一般過程
利用分析工具分析頁面載入資訊
利用分析工具分析效能瓶頸
效能調優的一般過程
在解決效能問題之前首先要確認問題的所在,首先就來看看確保高效能的一般過程:
1. 持續監控
2. 設定效能目標
3. 持續改進
1. 持續監控
網站的效能總體來說受兩個方面的影響:
一,我們可以控制的,例如代碼;
二,我們不能控制的,例如訪問使用者的數量,或者伺服器本身
特別是隨著網站的訪問量增大的時候,原來沒有出現的問題,現在可能出來了,不同的階段要解決的問題也是不一樣的。所以很有必要對網站進行持續的監控, 趁早發現網站變慢的原因。本篇的後面部門會介紹一些我們可以使用的監控服務,來協助我們做這些事情。
2. 設定效能目標
網站的效能如何,一個最直觀的感受就是:開啟這個網站之後,頁面載入的時間,這也是說是訪問者最直接的體驗。很多的最佳化工作(不管是前台的最佳化還是背景最佳化)都是為了讓使用者更快的看到所想看的頁面和資訊。我們後面的討論很多時候都是以這個為目標的。
首先必須要明白“快”的含義:一個網站的響應速度多快才算是“快”?因為最佳化網站需要花費很大的時間和精力,如果網站本身已經很快了,例如網頁呈現到使用者眼前的時間是毫秒層級的,我們確實可以再花時間讓它更快,但是這樣做起來成本會更高!
3.持續改進
在進行效能最佳化的時候,要涉及到很多的東西,所以在進行最佳化的時候必須確認:進行的最佳化措施確實的提高了網站的效能。為了達到這個目的,有幾個規則可以遵循:
1. 每次最佳化只改動一處。如果改動了很多處,那麼這些改動之間可能相互的影響,最後產生一些奇奇怪怪的現象,有時候這些"最佳化措施"反而使得網站效能降低。而且如果一次改動多次,也不利于衡量那些"最佳化措施"真真正正提升了網站的效能。
2. 不斷的測試。每次進行了所謂的"最佳化"之後,一定要測試一下,這個"最佳化"是否真的提升了效能,如果沒有提升,那麼就復原這個操作。
一般進行最佳化的步驟如下:
1. 記錄現在網站的效能指數和一些相關的資料(後面會告訴大家如何擷取這些效能指數資料)
2. 診斷網站的效能故障點.可能有幾個地方都影響了網站的效能,但是,此時我們只是選擇影響最大的那個因數進行最佳化。
3. 解決找出的效能故障點。
4. 測試。收集資料,和最佳化前進行比較,看看是否提升了效能。
5. 重複1到4步驟。
上面雖然提出了一些規則,但是我們可以靈活處理某些情況:在我們尋找影響效能的問題的時候,我們發現多個問題,而且這些問題根據我們的經驗判斷會影響效能,那麼我們可以同時修改此處。
我們用一個流程圖來總結上面的最佳化步驟。如下:
OK,今天就暫時發布這些,下一篇發布:利用分析工具分析效能瓶頸。
很有段時間沒有更新部落格了,多謝大家一致以來的關注和支援,在新的一年裡,努力為大家提供更多的博文,算是對朋友們的回饋,小洋再次感謝大家! :)