高性能ASP.NET站點構建之識別性能瓶頸

前言:從本篇開始就真正的進入了性能調優的階段,在以前的文章中提到了頁面加載過慢的四個性能問題,其中第一個問題就是:服務端解析<頁面的時間過長,本篇就分析這個問題,給出一些方案,由於涉及到的問題不少,的在後續文章會逐個詳細介紹。javascript

由於本篇的篇幅過長,因此劃分爲了多篇。 html

本篇的議題以下:java

識別和分析服務端的性能瓶頸(上)數據庫

內存瀏覽器

緩存緩存

CPU服務器

處理請求線程ide

提升性能的一些改進措施(下)工具

部署優化(前篇)性能

沒必要要回傳(中篇)

沒必要要的請求(後篇)

在服務端有不少能夠優化的地方,優化的話題也不少,在本篇中咱們主要關注:若是讓服務端更快的生成頁面,同時也關注若是更快的讓生成的頁面更快的到達客戶端瀏覽器。

其實咱們就是在優化下面的時間線

要縮短上面的那條時間線,就須要服務端更好的利用它的資源,例如更好的利用和分配內存資源,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的壓力。

 

處理請求線程

咱們知道:發送到服務器的每個請求,都是有應用程序池中的一個線程來處理的。並且用來處理請求的線程的數量是有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

相關文章
相關標籤/搜索