建構高性能ASP.NET站點 第六章—性能瓶頸診斷與初步調優（上篇）—識别性能瓶頸
前言：從本篇開始就真正的進入了性能調優的階段，在之前的文章中提到了頁面加載過慢的四個性能問題，其中第一個問題就是：服務端解析.aspx頁面的時間過長，本篇就分析這個問題，給出一些方案，因為涉及到的問題很多，的在後續文章會逐個詳細介紹。
因為本篇的篇幅過長，是以劃分為了多篇。
本篇的議題如下：
識别和分析服務端的性能瓶頸(上)
記憶體
緩存
CPU
處理請求線程
提高性能的一些改進措施（下）
部署優化(前篇)
不必要回傳(中篇)
不必要的請求(後篇)
在服務端有很多可以優化的地方，優化的話題也很多，在本篇中我們主要關注：如果讓服務端更快的生成頁面，同時也關注如果更快的讓生成的頁面更快的到達用戶端浏覽器。
其實我們就是在優化下面的時間線：
要縮短上面的那條時間線，就需要服務端更好的利用它的資源，例如更好的利用和配置設定記憶體資源，CPU資源等。如何好的充分利用這些資源，一定程度上與我們寫的代碼的品質息息相關，一段好的，高效的代碼往往可以讓我們少花錢去更多的硬體裝置（是以代碼的品質非常重要）。
下面我們就來看看服務端一般可能出現的性能瓶頸：
記憶體不足
缺乏緩存
CPU壓力
處理請求線程問題
接下來會介紹如何采用系統的性能診斷工具來辨明：到底是哪種性能瓶頸導緻了服務端解析頁面過慢。在用性能診斷工具找出了問題之後，然後針對問題再次做詳細的分析，同時收集資料，根據這些資料來采用對應的措施，對症下藥。至于每一種性能問題如何采取何種措施解決，我們後面的文章會一章章的詳細詳述，請大家稍安勿躁，在此我們先學會發現問題。發現站點的可能出現了性能問題之後，首先不要立刻的修改站點或者伺服器，而是要先診斷出瓶頸出現在哪裡。J
記憶體
首先要判斷伺服器是否記憶體不足。因為如果記憶體不足，那麼會增加伺服器的CPU壓力和磁盤的IO讀寫操作，發過來說，如果解決了記憶體不存的問題，自然而然的就減少了CPU和磁盤IO讀寫操作。
為什麼記憶體不存會增加CPU的壓力和磁盤的IO讀寫操作？
當系統的記憶體不足的時候，系統就會把原來需要放在記憶體的一些資料轉移儲存在磁盤上面，儲存為pagefile.sys。當這些資料被需要的時候，那麼系統就會去讀寫磁盤。讀寫磁盤的操作會消耗CPU資源，同時增加了磁盤的IO操作。
下面我們就來看看，如何識别記憶體不足性能瓶頸。
我們主要講述如何在Window伺服器系統中診斷這個問題。
Window Server 2003
在系統的指令行中輸入”perfom”。就會彈出如下的視窗。然後點選工具欄上面的”+”按鈕，在”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的壓力。
我們知道：發送到伺服器的每一個請求，都是有應用程式池中的一個線程來處理的。而且用來處理請求的線程的數量是有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的數量，那麼就說明有請求在等待被處理。後面的文章會詳細講述如何處理這種情況。
OK，今天就暫時發上這些，貴在了解和操作。下一篇接着講述。我在寫一些模拟上面性能瓶頸的代碼，有需要的朋友留個email。