高性能ASP.NET站點構建之識別性能瓶頸
高性能ASP.NET站點構建系列文章目錄
- 高性能ASP.NET站點構建之開篇
- 高性能ASP.NET站點構建之剖析頁面的處理過程
- 高性能ASP.NET站點構建之優化HTTP請求
- 高性能ASP.NET站點構建之細節決定成敗
- 高性能ASP.NET站點構建之性能調優綜述
- 高性能ASP.NET站點構建之識別性能瓶頸
- 高性能ASP.NET站點構建之簡單的優化措施
- ASP.NET站點構建之減少不必要的請求
- 高性能ASP.NET站點構建之托管資源優化
- 高性能ASP.NET站點構建之監測CLR性能
前言：從本篇開始就真正的進入了性能調優的階段，在之前的文章中提到了頁面加載過慢的四個性能問題，其中***個問題就是：服務端解析<頁面的時間過長，本篇就分析這個問題，給出一些方案，因為涉及到的問題很多，的在后續文章會逐個詳細介紹。
因為本篇的篇幅過長，所以劃分為了多篇。
本篇的議題如下：
識別和分析服務端的性能瓶頸(上)
內存
緩存
CPU
處理請求線程
提高性能的一些改進措施（下）
部署優化(前篇)
不必要回傳(中篇)
不必要的請求(后篇)
在服務端有很多可以優化的地方，優化的話題也很多，在本篇中我們主要關注：如果讓服務端更快的生成頁面，同時也關注如果更快的讓生成的頁面更快的到達客戶端瀏覽器。
其實我們就是在優化下面的時間線
要縮短上面的那條時間線，就需要服務端更好的利用它的資源，例如更好的利用和分配內存資源，CPU資源等。如何好的充分利用這些資源，一定程度上與我們寫的代碼的質量息息相關，一段好的，高效的代碼往往可以讓我們少花錢去更多的硬件設備（所以代碼的質量非常重要）。
下面我們就來看看服務端一般可能出現的性能瓶頸：
內存不足
缺乏緩存
CPU壓力
處理請求線程問題
接下來會介紹如何采用系統的性能診斷工具來辨明：到底是哪種性能瓶頸導致了服務端解析頁面過慢。在用性能診斷工具找出了問題之后，然后針對問題再次做詳細的分析，同時收集數據，根據這些數據來采用對應的措施，對癥下藥。至于每一種性能問題如何采取何種措施解決，我們后面的文章會一章章的詳細詳述，請大家稍安勿躁，在此我們先學會發現問題。發現站點的可能出現了性能問題之后，首先不要立刻的修改站點或者服務器，而是要先診斷出瓶頸出現在哪里。J
內存
首先要判斷服務器是否內存不足。因為如果內存不足，那么會增加服務器的CPU壓力和磁盤的IO讀寫操作，發過來說，如果解決了內存不存的問題，自然而然的就減少了CPU和磁盤IO讀寫操作。
為什么內存不存會增加CPU的壓力和磁盤的IO讀寫操作？
當系統的內存不足的時候，系統就會把原來需要放在內存的一些數據轉移保存在磁盤上面，保存為pagefile.sys。當這些數據被需要的時候，那么系統就會去讀寫磁盤。讀寫磁盤的操作會消耗CPU資源，同時增加了磁盤的IO操作。
下面我們就來看看，如何識別內存不足性能瓶頸。
我們主要講述如何在Window服務器系統中診斷這個問題。
Window Server 2003
在系統的命令行中輸入”perfmon”。就會彈出如下的窗口。然后點擊工具欄上面的”+”按鈕，在”Performance object”下拉框中選擇”Memory”，然后再選擇”Pages/sec”計數器。如果這個值很大，就說明CPU在內存和磁盤之間不斷的交換數據。
Windows Vista, Server 2008, Window 7
在Windows Vista和Windows Server 2008，Window 7中不僅可以運行”perfmon”，打開性能監視窗口。而且可以運行”resmon”來開啟資源監視窗口，從這個窗口看，可以更加直觀。在資源監視窗口中看到”硬錯誤/秒”(Hard Faults/sec).然后檢查每個進程的這個值，如果進程的”硬錯誤/秒”數值很高，那么就說明服務器已經是內存不足了。（我們將會在后續的文章講述如何解決這個問題，此處我們先講述如何找出這個問題
緩存
大家都知道，在適當的實用緩存策略可以極大的提高服務端的性能。我們一般把數據緩存在內存中，例如瀏覽器的內存，代理服務器的內存等。而且可以把一些常用的對象，部分的頁面，甚至整個頁面緩存起來。
緩存的好處有很多，如下：
縮短服務端的響應時間
減少CPU的使用壓力
避免頻繁的讀取數據庫
如果把數據緩存在瀏覽器或者代理服務器，還可以減少不必要的回傳
一般來說，我們把一些使用很頻繁的數據或者每次生成都要花費大量資源的數據緩存起來。
但是如何才算得上是”使用很頻繁”？
沒有一定的標準了，還是那句話：看情況！例如，如果一個頁面在1秒鐘之內被請求了10次，可能相比較其他的頁面而言，這個頁面的請求不算””頻繁（其他的頁面在1秒之內請求100次)，但是如果把這個頁面緩存1秒，也是對性能的極大提升，因為可以一秒之內，有90%的請求都是由緩存響應的。大家可以去參看一下”緩存的5分鐘法則”。至于如何進行緩存，在后面的文章講解。
CPU
還是和之前內存診斷一樣，我們可以運行”perfmon”命令，然后在”Processor”分類下面選”%Processor Time”計數器。如下
同時，我們還可運行”resmon”來打開“資源監視窗口”來看：
大家可以看到***個標紅色框的”CPU”列，其實這個就是反應了” %Processor Time”計數器監控的結果。一般來說，如果某個進程的這個值高于了80%，那么就說明這個進程對CPU資源有很大的消耗。如果是w3wp.exe這個進程消耗了80%，就說你的站點消耗了大量的CPU。我們會在后續的文章講述：如果減小CPU的壓力。
#p#
處理請求線程
我們知道：發送到服務器的每一個請求，都是有應用程序池中的一個線程來處理的。而且用來處理請求的線程的數量是有IIS來控制的，如果應用程序池中沒有空閑的線程來處理新的請求，那么這個請求就被放在請求隊列中進行等待。如果在服務端的請求隊列太長了，服務器忙不過來，那么新來的請求很有可能被服務器拒絕
一般來說，一個應用程序池中的可用的線程數量由服務端安裝的.NET Framework的版本和IIS的一些設置來決定的。
|
.NET Framework Version |
默認的可用線程數 |
|
1.1． |
20*CPU的數量-8 |
|
2.0 |
12* CPU的數量 |
|
3.5, 4.0 |
IIS 7經典模式:12* CPU的數量 |
|
|
IIS 7 集成模式: 100* CPU的數量 |
如果在服務端沒有足夠的線程來處理請求，這種情況就是所謂的”線程饑餓”。我們可以通過系統的性能計數器來檢查站點的服務端是否發生了這種情況：
1. 在命令窗口運行”perfmon”.如下：
2. 在打開的性能監視窗口中，選擇”性能監視器”，如下：
3. 點擊“+”按鈕，然后展開”ASP.NET”分類：
4. 添加如下計數器：
|
Request Execution Time |
處理一個請求花費的時間(單位是：毫秒) |
|
Request Current |
現在ASP.NET運行時要處理的請求數量，包括正在處理的請求和等待隊列中的請求。 |
5. 然后展開”ASP.NET Applications”分類，添加如下計數器：
|
Request Executing |
現在正在被處理的請求數 |
如果”Request Current”的數量大于了Request Executing的數量，那么就說明有請求在等待被處理。后面的文章會詳細講述如何處理這種情況。
如果”Request Current”的數量大于了Request Executing的數量，那么就說明有請求在等待被處理。后面的文章會詳細講述如何處理這種情況。
原文鏈接：http://www.cnblogs.com/yanyangtian/archive/2011/02/14/1954005.html
【編輯推薦】
- 高性能ASP.NET站點構建之開篇
- 高性能ASP.NET站點構建之剖析頁面的處理過程
- 高性能ASP.NET站點構建之優化HTTP請求
- 高性能ASP.NET站點構建之細節決定成敗
- 高性能ASP.NET站點構建之性能調優綜述
- 強化部署ASP.Net 2.0配置應用程序
- 微軟PDC2009直擊：改進ASP.NET 4運行時
