.NETRemotingServer性能分析及運(yùn)用Loadrunner進(jìn)行性能測(cè)試的方案

1概述

.NETRemoting被譽(yù)為管理應(yīng)用程序域之間的RPC的首選技術(shù)。應(yīng)用程序域是公共語(yǔ)言運(yùn)營(yíng)庫(kù)的隔離單元，它們是在進(jìn)程內(nèi)創(chuàng)建并運(yùn)營(yíng)的。這與CLR和非CLR托管的進(jìn)程之間的進(jìn)程間通信（互操作）不同。后一種類型的RPC通信（特別是Web上的）一般被認(rèn)為是Web服務(wù)領(lǐng)域的問(wèn)題。遺憾的是，這種看似清楚的區(qū)分，卻由于可以在IIS下集成.NetRemoting服務(wù)器而變得模糊，“通過(guò)在IIS中集成.NETRemoting對(duì)象，可以將其作為一種Web服務(wù)提供……”

Remoting，簡(jiǎn)而言之，我們可以將其看作是一種分布式解決方式。從微軟的產(chǎn)品角度來(lái)看，可以說(shuō)Remoting就是DCOM的一種升級(jí)，它改善了很多功能，并極好的融合到.Net平臺(tái)下。Microsoft?.NETRemoting提供了一種允許對(duì)象通過(guò)應(yīng)用程序域與另一對(duì)象進(jìn)行交互的框架。這也正是我們使用Remoting的因素。為什么呢？在Windows操作系統(tǒng)中，是將應(yīng)用程序分離為單獨(dú)的進(jìn)程。這個(gè)進(jìn)程形成了應(yīng)用程序代碼和數(shù)據(jù)周邊的一道邊界。假如不采用進(jìn)程間通信（RPC）機(jī)制，則在一個(gè)進(jìn)程中執(zhí)行的代碼就不能訪問(wèn)另一進(jìn)程。這是一種操作系統(tǒng)相應(yīng)用程序的保護(hù)機(jī)制。然而在某些情況下，我們需要跨過(guò)應(yīng)用程序域，與此外的應(yīng)用程序域進(jìn)行通信，即穿越邊界。其主機(jī)與客戶端的主要任務(wù)如下：

主機(jī)任務(wù)

·設(shè)計(jì)服務(wù)，選擇應(yīng)用程序域、激活模式、通道、端口和發(fā)布。

·實(shí)現(xiàn)Remoting主機(jī)應(yīng)用程序域（例如IIS/系統(tǒng)服務(wù)）。

·配置主機(jī)激活、通道和協(xié)議設(shè)立。建議使用配置文獻(xiàn)，可以通過(guò)調(diào)用RemotingConfiguration.Configure加載。

·發(fā)布接口，供客戶端使用（有關(guān)具體信息，請(qǐng)參閱下文中的“接口發(fā)布選擇”）。

客戶端任務(wù)

·設(shè)計(jì)客戶端，選擇應(yīng)用程序域和激活模式。

·考慮是否需要注冊(cè)通道和端口。

·獲取遠(yuǎn)程類型元數(shù)據(jù)。

·實(shí)現(xiàn)客戶端應(yīng)用程序域。

·配置客戶端激活模式和其他類型的信息，如應(yīng)用程序名稱、通道和對(duì)象URI等。建議使用配置文獻(xiàn)，可以通過(guò)調(diào)用RemotingConfiguration.Configure加載。

2Remoting解決方案的過(guò)程中也許會(huì)碰到的錯(cuò)誤情況

在任何情況下，都應(yīng)當(dāng)記住要使用標(biāo)準(zhǔn)的設(shè)備使用和監(jiān)視方法。事件記錄仍是非常有價(jià)值的信息資源，就象網(wǎng)絡(luò)監(jiān)視器工具同樣，網(wǎng)絡(luò)監(jiān)視器可以專門(mén)用于具體查看客戶端/服務(wù)器的Remoting會(huì)話。中間層的Remoting服務(wù)器仍可以使用VisualStudio.NET提供的標(biāo)準(zhǔn)調(diào)試工具進(jìn)行調(diào)試，例如，對(duì)于由IIS集成的Remoting服務(wù)器，可以通過(guò)向ASP.NET輔助進(jìn)程附加調(diào)試會(huì)話（VisualStudio.Net|Debug[調(diào)試]|Processes[進(jìn)程]|Attach[附加]）來(lái)設(shè)立斷點(diǎn)（假如資源可用）。但Remoting的錯(cuò)誤很獨(dú)特，下面列出了一些。請(qǐng)注意，所有錯(cuò)誤都已使用.NETFrameworkSDK提供的BasicRemotingHelloSample的各版本進(jìn)行了復(fù)現(xiàn)，服務(wù)器和客戶端也已在單機(jī)上運(yùn)營(yíng)。故障現(xiàn)象與在網(wǎng)絡(luò)鏈接上的相同，只是由于HTTP/TCP的超時(shí)設(shè)立不同，需要相稱長(zhǎng)的時(shí)間才干出現(xiàn)錯(cuò)誤。

2.1丟失MarshalByRef

由于Remoting要通過(guò)引用以用于給定的類，該類必須只做一件事，就是繼承MarshalByRefObject。假設(shè)開(kāi)發(fā)人員忘掉做這項(xiàng)工作，我們將得到一個(gè)System.Runtime.Remoting.RemotingException類型的異常，說(shuō)明我們有一個(gè)“丟失的MarshalByReference”.

是否能對(duì)的捕獲和解決這個(gè)RemotingException將取決于程序員。（想想這個(gè)開(kāi)發(fā)人員忘掉了他應(yīng)記住的唯一一件事。）

解決方法是：記住繼承MarshalByRefObject！

2.2眾所周知的服務(wù)器激活的錯(cuò)誤服務(wù)器端點(diǎn)

對(duì)于服務(wù)器激活，Remoting服務(wù)器將其偵聽(tīng)處聲明為端點(diǎn)。該端點(diǎn)一般涉及一個(gè)對(duì)象URI（遠(yuǎn)程對(duì)象的眾所周知名稱），一個(gè)協(xié)議和一個(gè)端標(biāo)語(yǔ)。當(dāng)然，所有這些都也許配置錯(cuò)誤。

2.3錯(cuò)誤的URI

由服務(wù)提供的BasicRemotingHelloSample的URI是HelloService.soap，如相關(guān)的web.config文獻(xiàn)中所指定：

<configuration>

<system.runtime.remoting>

<application>

<service>

<wellknownmode="SingleCall"type="Hello.HelloService,Hello"

objectUri="HelloService.soap"/>

</service>

</application>

</system.runtime.remoting>

</configuration>

此服務(wù)是IIS集成的。IIS集成規(guī)定URI帶有后綴.rem或.soap，我們?cè)诜?wù)器上使用.rope。在此實(shí)例中，我們將再次收到RemotingException，這次顯示的文本是“對(duì)象</Hello.soap>在服務(wù)器上已斷開(kāi)或不存在”。

請(qǐng)保證各個(gè)URI互相匹配！當(dāng)IIS集成Remoting服務(wù)器時(shí)，還要保證URI以.rem或.soap結(jié)尾。

2.4不匹配的協(xié)議/端口

為了進(jìn)行此項(xiàng)測(cè)試，我們切換到控制臺(tái)集成的服務(wù)器，以下是該服務(wù)器的配置文獻(xiàn)：

<configuration>

<system.runtime.remoting>

<applicationname="RemotingHello">

<service>

<wellknownmode="SingleCall"type="Hello.HelloService,Hello"

objectUri="HelloService.soap"/>

</service>

<channels>

<channelref="http"port="8000"/>

</channels>

</application>

</system.runtime.remoting>

</configuration>

假設(shè)我們要在服務(wù)器端將協(xié)議更改為T(mén)CP，而使客戶端保存HTTP。

我們將再次收到RemotingException，這次的文本是“底層連接已關(guān)閉：接受時(shí)出現(xiàn)意外錯(cuò)誤”。

端口設(shè)立錯(cuò)誤也會(huì)導(dǎo)致上述異常，唯一的不同是這種情況下，要用較長(zhǎng)的時(shí)間才會(huì)出現(xiàn)錯(cuò)誤。服務(wù)器和客戶端之間的端口和協(xié)議必須匹配。

2.5丟失URI

另一種也許性是遠(yuǎn)程服務(wù)器沒(méi)有運(yùn)營(yíng)，例如，服務(wù)器由IIS集成，而虛擬應(yīng)用程序或相關(guān)的程序集丟失。再次使用BasicHelloRemoting服務(wù)器，我們需要虛擬應(yīng)用程序RemotingHello可以運(yùn)營(yíng)。假如不能運(yùn)營(yíng)，我們將收到未解決的異常（取決于調(diào)用代碼），但這次的異常將是：“無(wú)法加載類型clr:Hello.HelloService,Hello”。

在這些情況下，請(qǐng)保證虛擬應(yīng)用程序在運(yùn)營(yíng)，并且所需的程序集對(duì)的地放置在相關(guān)的bin子文獻(xiàn)夾中。

總而言之，客戶端必須對(duì)的地引用服務(wù)器定義的端點(diǎn)以便激活服務(wù)器，這意味著，端口、協(xié)議和URI的定義必須互相匹配。這太容易犯錯(cuò)了。因此，假如服務(wù)器的位置定義為：

<service>

<wellknownmode="SingleCall"type="Hello.HelloService,Hello"

objectUri="HelloService.soap"/>

</service>

那么，客戶的設(shè)立必須為：

<clienturl="http://localhost/RemotingHello">

<wellknowntype="Hello.HelloService,Hello"

url="http://localhost/RemotingHello/HelloService.soap"/>

</client>

其中，URL表達(dá)集成Remoting服務(wù)的IIS虛擬應(yīng)用程序，類型表達(dá)類和程序集名稱。

3Remoting的特點(diǎn)

3.1優(yōu)點(diǎn)

他的優(yōu)點(diǎn)是用戶既可以使用TCP信道方式進(jìn)行二進(jìn)制流方式通信，也可以使用HTTP信道進(jìn)行SOAP格式的性通信

效率相對(duì)WebService要高不少；但是它的缺陷也很明顯，.netremoting只能應(yīng)用于MS的.netframework之下。

從性能上來(lái)講Remoting的效率和傳統(tǒng)的DCOM、COM+的性能很相近。

3.2缺陷

這種三層設(shè)計(jì)的缺陷與使用XMLWebservice的三層設(shè)計(jì)的缺陷相同。

所有業(yè)務(wù)規(guī)則均包含在前端代碼中。因而，假如需要更改業(yè)務(wù)規(guī)則，則必須更新所有客戶端。除非可以進(jìn)行自動(dòng)更新，否則這種維護(hù)工作將十分繁瑣。當(dāng)然，假如使用SQLServer，則可以將某些業(yè)務(wù)規(guī)則放到存儲(chǔ)過(guò)程中，從而減少維護(hù)的時(shí)間和成本。

所有字段名稱均在源代碼或控件屬性中硬編碼。假如更改字段名稱，則必須查找和替換應(yīng)用程序中所有該字段的名稱。假如使用了數(shù)據(jù)綁定，還必須檢查所有窗體并更改屬性。

通過(guò)網(wǎng)絡(luò)從一個(gè)組件向另一個(gè)組件傳輸數(shù)據(jù)比直接連接數(shù)據(jù)庫(kù)要慢。在Intranet方案中，.NETRemoting的性能比XMLWebservice要好。而在Internet方案中，一般不使用.NETRemoting。

建立這種應(yīng)用程序比建立兩層應(yīng)用程序或使用XMLWebservice的應(yīng)用程序要復(fù)雜一些。

必須使用比TCP速度慢的HTTP。此外，IIS也許循環(huán)執(zhí)行ASP.NET輔助進(jìn)程，這將破壞所有Singleton的狀態(tài)。對(duì)您來(lái)說(shuō)，這也許是問(wèn)題也也許不是問(wèn)題，要取決于您的設(shè)計(jì)需要，由于客戶端的下一個(gè)調(diào)用將重新啟動(dòng)Singleton。您可以將IIS配置為不循環(huán)執(zhí)行輔助進(jìn)程，但這種能力很有限，特別是在IIS5中，并且也許導(dǎo)致更進(jìn)一步的影響。這里最主線的意思是，假如規(guī)定遠(yuǎn)程服務(wù)器的安全性，那么無(wú)疑要使用IIS集成。

4調(diào)試小技巧

編寫(xiě)Remoting程序，通常分為三部分：遠(yuǎn)程對(duì)象、服務(wù)端程序、客戶端程序。假如不考慮元數(shù)據(jù)的安全性，我們會(huì)把遠(yuǎn)程對(duì)象的dll生成相同的兩份，分別放到服務(wù)端和客戶端。Remoting在客戶端的調(diào)用是很簡(jiǎn)樸的，但調(diào)試起來(lái)就沒(méi)有那么容易。由于客戶端和服務(wù)器端分別屬于不同的應(yīng)用程序域，無(wú)法設(shè)立斷點(diǎn)進(jìn)行單步調(diào)試。假如了解NUnit，大家會(huì)知道NUnit也是不支持分布式應(yīng)用程序的調(diào)試的，至少是支持得不夠好。

所以，在實(shí)際做項(xiàng)目的過(guò)程中，我更傾向于先調(diào)用本地的對(duì)象，等調(diào)試成功后，再打開(kāi)Remoting服務(wù)，調(diào)用遠(yuǎn)程對(duì)象，驗(yàn)證是否對(duì)的。舉例來(lái)說(shuō)，我要提供訪問(wèn)數(shù)據(jù)庫(kù)的遠(yuǎn)程對(duì)象。我會(huì)先讓該對(duì)象在本地運(yùn)營(yíng)，并調(diào)用其方法。假如一切正常，說(shuō)明數(shù)據(jù)庫(kù)的配置和連接均是對(duì)的的。然后再將該調(diào)用替換為遠(yuǎn)程對(duì)象。假如程序犯錯(cuò)，則可以肯定是Remoting提供的服務(wù)犯錯(cuò)了，或者是遠(yuǎn)程對(duì)象未按照Remoting的規(guī)定，沒(méi)有派生MarshalByRefObject，或者未提供序列化特性。

最初使用了最愚蠢的辦法，就是寫(xiě)兩行調(diào)用，一個(gè)調(diào)用本地對(duì)象，一個(gè)調(diào)用遠(yuǎn)程對(duì)象。然后根據(jù)實(shí)際的情況，酌情考慮注釋某一行代碼。如此這般用了一段時(shí)間，終于覺(jué)得麻煩，迫使改變方法了。其實(shí)很簡(jiǎn)樸，就是為客戶端程序的主類中，多寫(xiě)一個(gè)構(gòu)造函數(shù)而已，呵呵：）

例如，遠(yuǎn)程對(duì)象是一個(gè)訪問(wèn)數(shù)據(jù)庫(kù)的Remoting服務(wù)，派生MarshalByRefObject的主類名為DBAccessService。那么我一方面定義一個(gè)枚舉，分別標(biāo)明是屬于本地調(diào)用還是遠(yuǎn)程調(diào)用：

publicenumInvokeMode

{Local=0,Remoting}

對(duì)于客戶端程序，假如主類為DataBaseOperate，那么就需要增長(zhǎng)一個(gè)構(gòu)造函數(shù)和遠(yuǎn)程對(duì)象字段：

publicDataBaseOperate(InvokeModeinvokeMode)

{

switch(invokeMode)

{

caseInvokeMode.Local:

serviceObj=newDBAccessService();

break;

caseInvokeMode.Remoting:

serviceObj=(DBAccessService)Activator.GetObject(typeof(DBAccessService),"tcp://localhost:8080/DBAccessService");

break;

}

}

privateDBAccessServiceserviceObj=null;

如此這般，在客戶端調(diào)用對(duì)象時(shí)，就可根據(jù)設(shè)立構(gòu)造函數(shù)中的參數(shù)枚舉值，靈活地改變客戶端調(diào)用對(duì)象的方式。

其實(shí)這種辦法也可以用簡(jiǎn)樸工廠模式來(lái)完畢。但是這個(gè)簡(jiǎn)樸工廠生產(chǎn)的產(chǎn)品和通常意義的工廠模式有點(diǎn)不同樣哦，由于他們的產(chǎn)品其實(shí)是完全相同的。不同的僅僅是創(chuàng)建對(duì)象的方式而已。

publicclassSimpleFactory

{

publicstaticDBAccessServiceCreateInstance(InvokeModeinvokeMode)

{switch(invokeMode)

{

caseInvokeMode.Local:

returnnewDBAccessService();

break;

caseInvokeMode.Remoting:

return(DBAccessService)Activator.GetObject(typeof(DBAccessService),"tcp://localhost:8080/DBAccessService");

break;

}

}

}

然后再調(diào)用工廠的靜態(tài)方法，來(lái)獲得該對(duì)象即可。

兩種方法都是一種思想：就是根據(jù)需要，選擇不同的創(chuàng)建方式（其實(shí)前一種方法也可以看作是簡(jiǎn)樸工廠模式的一種變種）。假如只有一個(gè)要?jiǎng)?chuàng)建的對(duì)象，選前者更為方便；假如需要?jiǎng)?chuàng)建多個(gè)對(duì)象，用工廠方法提供多個(gè)靜態(tài)方法，應(yīng)當(dāng)要靈活一些。

通過(guò)上述方法，不僅便于調(diào)試，也便于以后代碼的修改。假如取消使用Remoting，只需改變參數(shù)枚舉值即可，其他代碼通通不用改變。這個(gè)技巧也算是設(shè)計(jì)模式的一種最簡(jiǎn)樸應(yīng)用吧。

5測(cè)試方案

分布式應(yīng)用程序中進(jìn)程間通信的性能取決于以下因素：

用于跨遠(yuǎn)程邊界的應(yīng)用程序間傳輸信息的通道（涉及TCP和HTTP）占用的系統(tǒng)開(kāi)銷量。TCP套接字比HTTP更為有效。

Remoting分別使用BinaryFormatter和SOAPFormatter將對(duì)象序列化為二進(jìn)制格式和SOAP格式。由于這些格式化程序使用反射，因而對(duì)于引用對(duì)象不久，但對(duì)于必須通過(guò)裝箱或取消裝箱來(lái)通過(guò)反射API傳遞的值類型則較慢。此外，SOAPFormatter還需要額外的系統(tǒng)開(kāi)銷以生成編碼的SOAP消息。

我們使用測(cè)試基于訪問(wèn)客戶和訂單數(shù)據(jù)的普通業(yè)務(wù)方案。為使測(cè)試盡也許符合實(shí)際，數(shù)據(jù)庫(kù)中包含100,000多行客戶帳戶。數(shù)據(jù)位于Orcale數(shù)據(jù)庫(kù)中。

性能比較中使用了以下方法：

FrmInputSalesOrder方法產(chǎn)生PKID并觸發(fā)btnConfirmOrder_Click事件。

FrmQueryCustomer方法接受CustomerId和參數(shù)以指定想要讀取的客戶行數(shù)目，并讀取CustomerId大于傳遞給Web服務(wù)方法的CustomerId的前n行。

測(cè)試過(guò)程中，我們逐頁(yè)提取不同類型客戶行集合，然后查詢商品，填寫(xiě)完銷售訂單后，提交保存。在這個(gè)過(guò)程中，用LR模擬100虛擬用戶同時(shí)進(jìn)行操作，檢測(cè)系統(tǒng)響應(yīng)時(shí)間及其他性能參數(shù)。

6測(cè)試工具和策略

6.1工具簡(jiǎn)介

在本測(cè)試中，我們使用了MI公司的loadrunner。它可以對(duì)Web服務(wù)器進(jìn)行強(qiáng)度測(cè)試，分析Web應(yīng)用程序（涉及ASPX頁(yè)及其使用的組件）的性能和可伸縮性問(wèn)題。有關(guān)如何創(chuàng)建和運(yùn)營(yíng)測(cè)試的具體信息，請(qǐng)參閱loadrunner使用手冊(cè)。通過(guò)打開(kāi)到服務(wù)器的多個(gè)連接并迅速發(fā)送HTTP請(qǐng)求，loadrunner可以模擬一大組用戶。它還允許我們建立實(shí)際的測(cè)試方案，我們可以在方案中使用一組隨機(jī)參數(shù)值調(diào)用同一個(gè)方法。此功能很重要，因?yàn)橛脩舨灰苍S會(huì)使用相同的參數(shù)值反復(fù)調(diào)用同一個(gè)方法。另一個(gè)有用的功能是，loadrunner可以記錄測(cè)試結(jié)果，然后進(jìn)行分析，從而提供有關(guān)Web應(yīng)用程序性能的最重要的信息。

6.2解決Loadrunner中沒(méi)有相關(guān)Remoting協(xié)議的問(wèn)題

因?yàn)樵贑/S的ERP系統(tǒng)中，LR并沒(méi)有remoting相關(guān)協(xié)議可以選擇，直接導(dǎo)致了LR無(wú)法錄制操作環(huán)節(jié)，取得腳本程序。解決這種狀況有一種方法，即：去MERCURY官方站點(diǎn)去下載一個(gè)基于.NETRemoting的add-in的補(bǔ)丁包，把此包集成于.NETC#開(kāi)發(fā)環(huán)境中，這時(shí)，開(kāi)發(fā)環(huán)境上方工具條會(huì)出現(xiàn)一個(gè)Vuser的新控件（見(jiàn)下圖）。我們調(diào)入被測(cè)源程序，然后在其中創(chuàng)建一個(gè)Loadrunner的新項(xiàng)目，然后根據(jù)被測(cè)對(duì)象，在開(kāi)發(fā)環(huán)境中寫(xiě)出測(cè)試代碼。最后運(yùn)用Vuser項(xiàng)創(chuàng)建LR的場(chǎng)景，它會(huì)自動(dòng)調(diào)用LR去做，設(shè)立完畢運(yùn)營(yíng)即可。當(dāng)完畢場(chǎng)景運(yùn)營(yíng)之后，運(yùn)用LR的Analysis工具進(jìn)行分析即可。

7LR計(jì)數(shù)器簡(jiǎn)介

Memory:

內(nèi)存使用情況也許是系統(tǒng)性能中最重要的因素。假如系統(tǒng)“頁(yè)互換”頻繁，說(shuō)明內(nèi)存局限性?！绊?yè)互換”是使用稱為“頁(yè)面”的單位，將固定大小的代碼和數(shù)據(jù)塊從RAM移動(dòng)到磁盤(pán)的過(guò)程，其目的是為了釋放內(nèi)存空間。盡管某些頁(yè)互換使Windows2023可以使用比實(shí)際更多的內(nèi)存，也是可以接受的，但頻繁的頁(yè)互換將減少系統(tǒng)性能。減少頁(yè)互換將顯著提高系統(tǒng)響應(yīng)速度。要監(jiān)視內(nèi)存局限性的狀況，請(qǐng)從以下的對(duì)象計(jì)數(shù)器開(kāi)始：

AvailableMbytes:

可用物理內(nèi)存數(shù).假如AvailableMbytes的值很小（4MB或更?。?，則說(shuō)明計(jì)算機(jī)上總的內(nèi)存也許局限性，或某程序沒(méi)有釋放內(nèi)存。

page/sec:

表明由于硬件頁(yè)面錯(cuò)誤而從磁盤(pán)取出的頁(yè)面數(shù)，或由于頁(yè)面錯(cuò)誤而寫(xiě)入磁盤(pán)以釋放工作集空間的頁(yè)面數(shù)。一般假如pages/sec連續(xù)高于幾百，那么您應(yīng)當(dāng)進(jìn)一步研究頁(yè)互換活動(dòng)。有也許需要增長(zhǎng)內(nèi)存，以減少換頁(yè)的需求（你可以把這個(gè)數(shù)字乘以4k就得到由此引起的硬盤(pán)數(shù)據(jù)流量）。Pages/sec的值很大不一定表白內(nèi)存有問(wèn)題，而也許是運(yùn)營(yíng)使用內(nèi)存映射文獻(xiàn)的程序所致。

pageread/sec:

頁(yè)的硬故障，page/sec的子集，為了解析對(duì)內(nèi)存的引用，必須讀取頁(yè)文獻(xiàn)的次數(shù)。閾值為>5.越低越好。大數(shù)值表達(dá)磁盤(pán)讀而不是緩存讀。

由于過(guò)多的頁(yè)互換要使用大量的硬盤(pán)空間，因此有也許將導(dǎo)致將頁(yè)互換內(nèi)存局限性與導(dǎo)致頁(yè)互換的磁盤(pán)瓶徑混淆。因此，在研究?jī)?nèi)存局限性不太明顯的頁(yè)互換的因素時(shí)，必須跟蹤如下的磁盤(pán)使用情況計(jì)數(shù)器和內(nèi)存計(jì)數(shù)器：

PhysicalDisk%DiskTime、PhysicalDiskAvg.DiskQueueLength例如，涉及PageReads/sec和%DiskTime及Avg.DiskQueueLength。假如頁(yè)面讀取操作速率很低，同時(shí)%DiskTime和Avg.DiskQueueLength的值很高，則也許有磁盤(pán)瓶徑。但是，假如隊(duì)列長(zhǎng)度增長(zhǎng)的同時(shí)頁(yè)面讀取速率并未減少，則內(nèi)存局限性。

要擬定過(guò)多的頁(yè)互換對(duì)磁盤(pán)活動(dòng)的影響，請(qǐng)將PhysicalDiskAvg.Disksec/Transfer和MemoryPages/sec計(jì)數(shù)器的值增大數(shù)倍。假如這些計(jì)數(shù)器的計(jì)數(shù)結(jié)果超過(guò)了0.1，那么頁(yè)互換將花費(fèi)百分之十以上的磁盤(pán)訪問(wèn)時(shí)間。假如長(zhǎng)時(shí)間發(fā)生這種情況，那么您也許需要更多的內(nèi)存。

PageFaults/sec:

每秒軟性頁(yè)面失效的數(shù)目（涉及有些可以直接在內(nèi)存中滿足而有些需要從硬盤(pán)讀取）較page/sec只表白數(shù)據(jù)不能在內(nèi)存的指定工作集中立即使用。

CacheBytes：

文獻(xiàn)系統(tǒng)緩存（FileSystemCache），默認(rèn)情況下為50%的可用物理內(nèi)存。如IIS5.0運(yùn)營(yíng)內(nèi)存不夠時(shí)，它會(huì)自動(dòng)整理緩存。

需要關(guān)注該計(jì)數(shù)器的趨勢(shì)變化

如果您懷疑有內(nèi)存泄露，請(qǐng)監(jiān)視MemoryAvailableBytes和MemoryCommittedBytes，以觀測(cè)內(nèi)存行為，并監(jiān)視您認(rèn)為也許在泄露內(nèi)存的進(jìn)程的ProcessPrivateBytes、ProcessWorkingSet和ProcessHandleCount。假如您懷疑是內(nèi)核模式進(jìn)程導(dǎo)致了泄露，則還應(yīng)當(dāng)監(jiān)視MemoryPoolNonpagedBytes、MemoryPoolNonpagedAllocs和Process(process_name)PoolNonpagedBytes。

Pagespersecond:

每秒鐘檢索的頁(yè)數(shù)。該數(shù)字應(yīng)少于每秒一頁(yè)。

Process：

%ProcessorTime:

被解決器消耗的解決器時(shí)間數(shù)量。假如服務(wù)器專用于sqlserver,可接受的最大上限是80-85%

PageFaults/sec:將進(jìn)程產(chǎn)生的頁(yè)故障與系統(tǒng)產(chǎn)生的相比較，以判斷這個(gè)進(jìn)程對(duì)系統(tǒng)頁(yè)故障產(chǎn)生的影響。

Workset:

解決線程最近使用的內(nèi)存頁(yè)，反映了每一個(gè)進(jìn)程使用的內(nèi)存頁(yè)的數(shù)量。假如服務(wù)器有足夠的空閑內(nèi)存，頁(yè)就會(huì)被留在工作集中，當(dāng)自由內(nèi)存少于一個(gè)特定的閾值時(shí)，頁(yè)就會(huì)被清除出工作集。

Inetinfo:PrivateBytes:

此進(jìn)程所分派的無(wú)法與其它進(jìn)程共享的當(dāng)前字節(jié)數(shù)量。假如系統(tǒng)性能隨著時(shí)間而減少，則此計(jì)數(shù)器可以是內(nèi)存泄漏的最佳指示器。

Processor：監(jiān)視“解決器”和“系統(tǒng)”對(duì)象計(jì)數(shù)器可以提供關(guān)于解決器使用的有價(jià)值的信息，幫助您決定是否存在瓶頸。

%ProcessorTime:

假如該值連續(xù)超過(guò)95%，表白瓶頸是CPU?？梢钥紤]增長(zhǎng)一個(gè)解決器或換一個(gè)更快的解決器。

%UserTime:

表達(dá)花費(fèi)CPU的數(shù)據(jù)庫(kù)操作，如排序，執(zhí)行aggregatefunctions等。假如該值很高，可考慮增長(zhǎng)索引，盡量使用簡(jiǎn)樸的表聯(lián)接，水平分割大表格等方法來(lái)減少該值。

%PrivilegedTime：

（CPU內(nèi)核時(shí)間）是在特權(quán)模式下解決線程執(zhí)行代碼所花時(shí)間的比例。假如該參數(shù)值和"PhysicalDisk"參數(shù)值一直很高，表白I/O有問(wèn)題。可考慮更換更快的硬盤(pán)系統(tǒng)。此外設(shè)立TempdbinRAM，減低"maxasyncIO"，"maxlazywriterIO"等措施都會(huì)減少該值。

此外，跟蹤計(jì)算機(jī)的服務(wù)器工作隊(duì)列當(dāng)前長(zhǎng)度的ServerWorkQueuesQueueLength計(jì)數(shù)器會(huì)顯示出解決器瓶頸。隊(duì)列長(zhǎng)度連續(xù)大于4則表達(dá)也許出現(xiàn)解決器擁塞。此計(jì)數(shù)器是特定期間的值，而不是一段時(shí)間的平均值。

%DPCTime:

越低越好。在多解決器系統(tǒng)中，假如這個(gè)值大于50%并且Processor:%ProcessorTime非常高，加入一個(gè)網(wǎng)卡也許會(huì)提高性能，提供的網(wǎng)絡(luò)已經(jīng)不飽和。

Process

%ProcessorTime指這個(gè)線程使用解決器執(zhí)行指令的所用時(shí)間的比例。類似于Processor的%ProcessorTime

%PrivilegedTime指這臺(tái)解決器的線程用于執(zhí)行在特權(quán)模式中的代碼所通過(guò)時(shí)間的比例。類似于Processor的%PrivilegedTime

%UserTime指這臺(tái)解決的線程用于執(zhí)行使用用戶模式的代碼的時(shí)間的比例。類似于Processor的%UserTime

PrivateBytes指這個(gè)解決不能與其它解決共享的、已分派的當(dāng)前字節(jié)數(shù)。假如此數(shù)值隨時(shí)間不斷增大，有也許是內(nèi)存泄漏。

VirtualBytes指解決使用的虛擬地址空間的以字節(jié)數(shù)顯示的當(dāng)前大小。使用虛擬地址空間不一定是指對(duì)磁盤(pán)或主內(nèi)存頁(yè)的相應(yīng)的使用。虛擬空間是有限，假如使用過(guò)多，也許會(huì)限制解決加載數(shù)據(jù)庫(kù)的能力。

IODataBytes/sec解決從I/O操作讀取/寫(xiě)入字節(jié)的速度。這個(gè)計(jì)數(shù)器為所有由本解決產(chǎn)生的涉及文獻(xiàn)、網(wǎng)絡(luò)和設(shè)備I/O的活動(dòng)計(jì)數(shù)。

Processor

%ProcessorTime指解決器執(zhí)行非閑置線程時(shí)間的比例。這個(gè)計(jì)數(shù)器設(shè)計(jì)成用來(lái)作為解決器活動(dòng)的重要指示器。它通過(guò)在每個(gè)范例間隔中衡量解決器用于執(zhí)行閑置解決線程的時(shí)間，并且用100%減去該值得出。(每臺(tái)解決器有一個(gè)閑置線程，該線程在沒(méi)有其它線程可以運(yùn)營(yíng)時(shí)消耗周期)?？蓪⑵湟暈榉独g隔用于做有用工作的比例。這個(gè)計(jì)數(shù)器顯示在范例間隔時(shí)所看到的忙時(shí)平均值。這個(gè)值是用100%減去該服務(wù)不活動(dòng)的時(shí)間計(jì)算出來(lái)的。

正常值<90，此值過(guò)大表達(dá)解決器的性能已經(jīng)不能應(yīng)付程序的規(guī)定，要換更快的解決器。

%PrivilegedTime指非閑置解決器時(shí)間用于特權(quán)模式的比例。(特權(quán)模式是為操作系統(tǒng)組件和操縱硬件驅(qū)動(dòng)程序而設(shè)計(jì)的一種解決模式。它允許直接訪問(wèn)硬件和所有內(nèi)存。另一種模式為用戶模式，它是一種為應(yīng)用程序、環(huán)境分系統(tǒng)和整數(shù)分系統(tǒng)設(shè)計(jì)的一種有限解決模式。操作系統(tǒng)將應(yīng)用程序線程轉(zhuǎn)換成特權(quán)模式以訪問(wèn)操作系統(tǒng)服務(wù))。特權(quán)時(shí)間的%涉及為間斷和DPC提供服務(wù)的時(shí)間。特權(quán)時(shí)間比率高也許是由于失敗設(shè)備產(chǎn)生的大