| 導購 | 订阅 | 在线投稿
分享
 
 
當前位置: 王朝網路 >> asp >> ASP.NET常用的26個優化性能方法
 

ASP.NET常用的26個優化性能方法

2008-07-26 07:41:52  編輯來源:互聯網  简体版  手機版  評論  字體: ||
 
 
  1. 數據庫訪問性能優化

  數據庫的連接和關閉

  訪問數據庫資源需要創建連接、打開連接和關閉連接幾個操作。這些過程需要多次與數據庫交換信息以通過身份驗證,比較耗費服務器資源。ASP.NET中提供了連接池(Connection Pool)改善打開和關閉數據庫對性能的影響。系統將用戶的數據庫連接放在連接池中,需要時取出,關閉時收回連接,等待下一次的連接請求。連接池的大小是有限的,如果在連接池達到最大限度後仍要求創建連接,必然大大影響性能。因此,在建立數據庫連接後只有在真正需要操作時才打開連接,使用完畢後馬上關閉,從而盡量減少數據庫連接打開的時間,避免出現超出連接限制的情況。

  使用存儲過程

  存儲過程是存儲在服務器上的一組預編譯的SQL語句,類似于DOS系統中的批處理文件。存儲過程具有對數據庫立即訪問的功能,信息處理極爲迅速。使用存儲過程可以避免對命令的多次編譯,在執行一次後其執行規劃就駐留在高速緩存中,以後需要時只需直接調用緩存中的二進制代碼即可。另外,存儲過程在服務器端運行,獨立于ASP.NET程序,便于修改,最重要的是它可以減少數據庫操作語句在網絡中的傳輸。

  優化查詢語句

  ASP.NET中ADO連接消耗的資源相當大,SQL語句運行的時間越長,占用系統資源的時間也越長。因此,盡量使用優化過的SQL語句以減少執行時間。比如,不在查詢語句中包含子查詢語句,充分利用索引等。

  2. 字符串操作性能優化

  使用值類型的ToString方法

  在連接字符串時,經常使用"+"號直接將數字添加到字符串中。這種方法雖然簡單,也可以得到正確結果,但是由于涉及到不同的數據類型,數字需要通過裝箱操作轉化爲引用類型才可以添加到字符串中。但是裝箱操作對性能影響較大,因爲在進行這類處理時,將在托管堆中分配一個新的對象,原有的值複制到新創建的對象中。使用值類型的ToString方法可以避免裝箱操作,從而提高應用程序性能。

  運用StringBuilder類

  String類對象是不可改變的,對于String對象的重新賦值在本質上是重新創建了一個String對象並將新值賦予該對象,其方法ToString對性能的提高並非很顯著。在處理字符串時,最好使用StringBuilder類,其.NET 命名空間是System.Text。該類並非創建新的對象,而是通過Append,Remove,Insert等方法直接對字符串進行操作,通過ToString方法返回操作結果。 其定義及操作語句如下所示:

  int num;

  System.Text.StringBuilder str = new System.Text.StringBuilder(); //創建字符串

  str.Append(num.ToString()); //添加數值num

  Response.Write(str.ToString); //顯示操作結果

  3. 優化 Web 服務器計算機和特定應用程序的配置文件以符合您的特定需要

  默認情況下,ASP.NET 配置被設置成啓用最廣泛的功能並盡量適應最常見的方案。因此,應用程序開發人員可以根據應用程序所使用的功能,優化和更改其中的某些配置,以提高應用程序的性能。下面的列表是您應該考慮的一些選項。

  僅對需要的應用程序啓用身份驗證。

  默認情況下,身份驗證模式爲 Windows,或集成 NTLM。大多數情況下,對于需要身份驗證的應用程序,最好在 Machine.config 文件中禁用身份驗證,並在 Web.config 文件中啓用身份驗證。根據適當的請求和響應編碼設置來配置應用程序。ASP.NET 默認編碼格式爲 UTF-8。如果您的應用程序爲嚴格的 ASCII,請配置應用程序使用 ASCII 以獲得稍許的性能提高。

  考慮對應用程序禁用 AutoEventWireup。

  在 Machine.config 文件中將 AutoEventWireup 屬性設置爲 false,意味著頁面不將方法名與事件進行匹配和將兩者挂鈎(例如 Page_Load)。如果頁面開發人員要使用這些事件,需要在基類中重寫這些方法(例如,需要爲頁面加載事件重寫 Page.OnLoad,而不是使用 Page_Load 方法)。如果禁用 AutoEventWireup,頁面將通過將事件連接留給頁面作者而不是自動執行它,獲得稍許的性能提升。

  從請求處理管線中移除不用的模塊。

  默認情況下,服務器計算機的 Machine.config 文件中 節點的所有功能均保留爲激活。根據應用程序所使用的功能,您可以從請求管線中移除不用的模塊以獲得稍許的性能提升。檢查每個模塊及其功能,並按您的需要自定義它。例如,如果您在應用程序中不使用會話狀態和輸出緩存,則可以從 列表中移除它們,以便請求在不執行其他有意義的處理時,不必執行每個模塊的進入和離開代碼。

  4. 一定要禁用調試模式

  在部署生産應用程序或進行任何性能測量之前,始終記住禁用調試模式。如果啓用了調試模式,應用程序的性能可能受到非常大的影響。

  5. 對于廣泛依賴外部資源的應用程序,請考慮在多處理器計算機上啓用網絡園藝

  ASP.NET 進程模型幫助啓用多處理器計算機上的可縮放性,將工作分發給多個進程(每個CPU一個),並且每個進程都將處理器關系設置爲其 CPU。此技術稱爲網絡園藝。如果應用程序使用較慢的數據庫服務器或調用具有外部依賴項的 COM 對象(這裏只是提及兩種可能性),則爲您的應用程序啓用網絡園藝是有益的。但是,在決定啓用網絡園藝之前,您應該測試應用程序在網絡園中的執行情況。

  6. 只要可能,就緩存數據和頁輸出

  ASP.NET 提供了一些簡單的機制,它們會在不需要爲每個頁請求動態計算頁輸出或數據時緩存這些頁輸出或數據。另外,通過設計要進行緩存的頁和數據請求(特別是在站點中預期將有較大通訊量的區域),可以優化這些頁的性能。與 .NET Framework 的任何 Web 窗體功能相比,適當地使用緩存可以更好的提高站點的性能,有時這種提高是超數量級的。使用 ASP.NET 緩存機制有兩點需要注意。首先,不要緩存太多項。緩存每個項均有開銷,特別是在內存使用方面。不要緩存容易重新計算和很少使用的項。其次,給緩存的項分配的有效期不要太短。很快到期的項會導致緩存中不必要的周轉,並且經常導致更多的代碼清除和垃圾回收工作。若關心此問題,請監視與 ASP.NET Applications 性能對象關聯的 Cache Total Turnover Rate 性能計數器。高周轉率可能說明存在問題,特別是當項在到期前被移除時。這也稱作內存壓力。

  7. 選擇適合頁面或應用程序的數據查看機制

  根據您選擇在 Web 窗體頁顯示數據的方式,在便利和性能之間常常存在著重要的權衡。例如,DataGrid Web 服務器控件可能是一種顯示數據的方便快捷的方法,但就性能而言它的開銷常常是最大的。在某些簡單的情況下,您通過生成適當的 HTML 自己呈現數據可能很有效,但是自定義和浏覽器定向會很快抵銷所獲得的額外功效。Repeater Web 服務器控件是便利和性能的折衷。它高效、可自定義且可編程。

  8. 將 SqlDataReader 類用于快速只進數據遊標

  SqlDataReader 類提供了一種讀取從 SQL Server 數據庫檢索的只進數據流的方法。如果當創建 ASP.NET 應用程序時出現允許您使用它的情況,則 SqlDataReader 類提供比 DataSet 類更高的性能。情況之所以這樣,是因爲 SqlDataReader 使用 SQL Server 的本機網絡數據傳輸格式從數據庫連接直接讀取數據。另外,SqlDataReader 類實現 IEnumerable 接口,該接口也允許您將數據綁定到服務器控件。有關更多信息,請參見 SqlDataReader 類。有關 ASP.NET 如何訪問數據的信息,請參見通過 ASP.NET 訪問數據。

  9. 將 SQL Server 存儲過程用于數據訪問

  在 .NET Framework 提供的所有數據訪問方法中,基于 SQL Server 的數據訪問是生成高性能、可縮放 Web 應用程序的推薦選擇。使用托管 SQL Server 提供程序時,可通過使用編譯的存儲過程而不是特殊查詢獲得額外的性能提高。

  10. 避免單線程單元 (STA) COM 組件

  默認情況下,ASP.NET 不允許任何 STA COM 組件在頁面內運行。若要運行它們,必須在 .aspx 文件內將 ASPCompat=true 屬性包含在 @ Page 指令中。這樣就將執行用的線程池切換到 STA 線程池,而且使 HttpContext 和其他內置對象可用于 COM 對象。前者也是一種性能優化,因爲它避免了將多線程單元 (MTA) 封送到 STA 線程的任何調用。使用 STA COM 組件可能大大損害性能,應盡量避免。若必須使用 STA COM 組件,如在任何 interop 方案中,則應在執行期間進行大量調用並在每次調用期間發送盡可能多的信息。另外,小心不要在構造頁面期間創建任何 STA COM 組件。例如下面的代碼中,在頁面構造時將實例化由某個線程創建的 MySTAComponent,而該線程並不是將運行頁面的 STA 線程。這可能對性能有不利影響,因爲要構造頁面就必須完成 MTA 和 STA 線程之間的封送處理。

  <%@ Page Language="VB" ASPCompat="true" %>

  <script. runat=server>

  Dim myComp as new MySTAComponent()

  Public Sub Page_Load()

  myComp.Name = "Bob"

  End Sub

  </script>

  <html>

  <%

  Response.Write(myComp.SayHello)

  %>Response.Write(myComp.SayHello)

  %>

  </html>

  首選機制是推遲對象的創建,直到以後在 STA 線程下執行上述代碼,如下面的例子所示。

  <%@ Page Language="VB" ASPCompat="true" %>

  <script. runat=server>

  Dim myComp

  Public Sub Page_Load()

  myComp = new MySTAComponent()

  myComp.Name = "Bob"

  End Sub

  </script>

  <html>

  <%

  Response.Write(myComp.SayHello)

  %>Response.Write(myComp.SayHello)

  %>

  </html>

  推薦的做法是在需要時或者在 Page_Load 方法中構造任何 COM 組件和外部資源。永遠不要將任何 STA COM 組件存儲在可以由構造它的線程以外的其他線程訪問的共享資源裏。這類資源包括像緩存和會話狀態這樣的資源。即使 STA 線程調用 STA COM 組件,也只有構造此 STA COM 組件的線程能夠實際爲該調用服務,而這要求封送處理對創建者線程的調用。此封送處理可能産生重大的性能損失和可伸縮性問題。在這種情況下,請研究一下使 COM 組件成爲 MTA COM 組件的可能性,或者更好的辦法是遷移代碼以使對象成爲托管對象。

  11. 將調用密集型的 COM 組件遷移到托管代碼

  .NET Framework 提供了一個簡單的方法與傳統的 COM 組件進行交互。其優點是可以在保留現有投資的同時利用新的平台。但是在某些情況下,保留舊組件的性能開銷使得將組件遷移到托管代碼是值得的。每一情況都是不一樣的,決定是否需要遷移組件的最好方法是對 Web 站點運行性能測量。建議您研究一下如何將需要大量調用以進行交互的任何COM 組件遷移到托管代碼。許多情況下不可能將舊式組件遷移到托管代碼,特別是在最初遷移 Web 應用程序時。在這種情況下,最大的性能障礙之一是將數據從非托管環境封送到托管環境。因此,在交互操作中,請在任何一端執行盡可能多的任務,然後進行一個大調用而不是一系列小調用。例如,公共語言運行庫中的所有字符串都是 Unicode 的,所以應在調用托管代碼之前將組件中的所有字符串轉換成 Unicode 格式。另外,一處理完任何 COM 對象或本機資源就釋放它們。這樣,其他請求就能夠使用它們,並且最大限度地減少了因稍後請求垃圾回收器釋放它們所引起的性能問題。

  12. 在 Visual Basic .NET 或 JScript. 代碼中使用早期綁定

  以往,開發人員喜歡使用 Visual Basic、VBScript. 和 JScript. 的原因之一就是它們所謂「無類型」的性質。變量不需要顯式類型聲明,並能夠簡單地通過使用來創建它們。當從一個類型到另一個類型進行分配時,轉換將自動執行。不過,這種便利會大大損害應用程序的性能。Visual Basic 現在通過使用 Option Strict 編譯器指令來支持類型安全編程。爲了向後兼容,默認情況下,ASP.NET 不啓用該選項。但是,爲了得到最佳性能,強烈建議在頁中啓用該選項。若要啓用 Option Strict,請將 Strict 屬性包括在 @ Page 指令中,或者,對于用戶控件,請將該屬性包括在 @ Control 指令中。下面的示例演示了如何設置該屬性,並進行了四個變量調用以顯示使用該屬性是如何導致編譯器錯誤的。

  <%@ Page Language="VB" Strict="true" %>

  <%

  Dim B

  Dim C As String

  ' This will cause a compiler error.

  A = "Hello"

  ' This will cause a compiler error.

  B = "World"

  ' This will not cause a compiler error.

  C = "!!!!!!"

  ' But this will cause a compiler error.

  C = 0

  %>Dim B

  Dim C As String

  ' This will cause a compiler error.

  A = "Hello"

  ' This will cause a compiler error.

  B = "World"

  ' This will not cause a compiler error.

  C = "!!!!!!"

  ' But this will cause a compiler error.

  C = 0

  %> JScript. .NET 也支持無類型編程,但它不提供強制早期綁定的編譯器指令。若發生下面任何一種情況,則變量是晚期綁定的:被顯式聲明爲 Object,是無類型聲明的類的字段,是無顯式類型聲明的專用函數或方法成員,並且無法從其使用推斷出類型。 最後一個差別比較複雜,因爲如果 JScript. .NET 編譯器可以根據變量的使用情況推斷出類型,它就會進行優化。在下面的示例中,變量 A 是早期綁定的,但變量 B 是晚期綁定的。

  var A;

  var B;

  A = "Hello";

  B = "World";

  B = 0; 爲了獲得最佳的性能,當聲明 JScript. .NET 變量時,請爲其分配一個類型。例如,var A : String。

  13. 使請求管線內的所有模塊盡可能高效

  請求管線內的所有模塊在每次請求中都有機會被運行。因此,當請求進入和離開模塊時快速地觸發代碼至關重要,特別是在不使用模塊功能的代碼路徑裏。分別在使用及不使用模塊和配置文件時執行吞吐量測試,對確定這些方法的執行速度非常有用。

  14. 使用 HttpServerUtility.Transfer 方法在同一應用程序的頁面間重定向

  采用 Server.Transfer 語法,在頁面中使用該方法可避免不必要的客戶端重定向。

  15. 必要時調整應用程序每個輔助進程的線程數

  ASP.NET 的請求結構試圖在執行請求的線程數和可用資源之間達到一種平衡。已知一個使用足夠 CPU 功率的應用程序,該結構將根據可用于請求的 CPU 功率,來決定允許同時執行的請求數。這項技術稱作線程門控。但是在某些條件下,線程門控算法不是很有效。通過使用與 ASP.NET Applications 性能對象關聯的 Pipeline Instance Count 性能計數器,可以在 PerfMon 中監視線程門控。當頁面調用外部資源,如數據庫訪問或 XML Web services 請求時,頁面請求通常停止並釋放 CPU。如果某個請求正在等待被處理,並且線程池中有一個線程是自由的,那麽這個正在等待的請求將開始被處理。遺憾的是,有時這可能導致 Web 服務器上存在大量同時處理的請求和許多正在等待的線程,而它們對服務器性能有不利影響。通常,如果門控因子是外部資源的響應時間,則讓過多請求等待資源,對 Web 服務器的吞吐量並無幫助。爲緩和這種情況,可以通過更改 Machine.config 配置文件節點的 maxWorkerThreads 和 maxIOThreads 屬性,手動設置進程中的線程數限制。

  注意:輔助線程是用來處理 ASP.NET 請求的,而 IO 線程則是用于爲來自文件、數據庫或 XML Web services 的數據提供服務的。分配給這些屬性的值是進程中每個 CPU 每類線程的最大數目。對于雙處理器計算機,最大數是設置值的兩倍。對于四處理器計算機,最大值是設置值的四倍。無論如何,對于有四個或八個 CPU 的計算機,最好更改默認值。對于有一個或兩個處理器的計算機,默認值就可以,但對于有更多處理器的計算機的性能,進程中有一百或兩百個線程則弊大于利。注意進程中有太多線程往往會降低服務器的速度,因爲額外的上下文交換導致操作系統將 CPU 周期花在維護線程而不是處理請求上。

  16. 適當地使用公共語言運行庫的垃圾回收器和自動內存管理

  小心不要給每個請求分配過多內存,因爲這樣垃圾回收器將必須更頻繁地進行更多的工作。另外,不要讓不必要的指針指向對象,因爲它們將使對象保持活動狀態,並且應盡量避免含 Finalize 方法的對象,因爲它們在後面會導致更多的工作。特別是在 Finalize 調用中永遠不要釋放資源,因爲資源在被垃圾回收器回收之前可能一直消耗著內存。最後這個問題經常會對 Web 服務器環境的性能造成毀滅性的打擊,因爲在等待 Finalize 運行時,很容易耗盡某個特定的資源。

  17. 如果有大型 Web 應用程序,可考慮執行預批編譯

  每當發生對目錄的第一次請求時都會執行批編譯。如果目錄中的頁面沒有被分析並編譯,此功能會成批分析並編譯目錄中的所有頁面,以便更好地利用磁盤和內存。如果這需要很長時間,則將快速分析並編譯單個頁面,以便請求能被處理。此功能帶給 ASP.NET 性能上的好處,因爲它將許多頁面編譯爲單個程序集。從已加載的程序集訪問一頁比每頁加載新的程序集要快。批編譯的缺點在于:如果服務器接收到許多對尚未編譯的頁面的請求,那麽當 Web 服務器分析並編譯它們時,性能可能較差。爲解決這個問題,可以執行預批編譯。爲此,只需在應用程序激活之前向它請求一個頁面,無論哪頁均可。然後,當用戶首次訪問您的站點時,頁面及其程序集將已被編譯。沒有簡單的機制可以知道批編譯何時發生。需一直等到 CPU 空閑或者沒有更多的編譯器進程(例如 csc.exe(C# 編譯器)或 vbc.exe(Visual Basic 編譯器))啓動。還應盡量避免更改應用程序的 bin 目錄中的程序集。更改頁面會導致重新分析和編譯該頁,而替換 bin 目錄中的程序集則會導致完全重新批編譯該目錄。在包含許多頁面的大規模站點上,更好的辦法可能是根據計劃替換頁面或程序集的頻繁程度來設計不同的目錄結構。不常更改的頁面可以存儲在同一目錄中並在特定的時間進行預批編譯。經常更改的頁面應在它們自己的目錄中(每個目錄最多幾百頁)以便快速編譯。Web 應用程序可以包含許多子目錄。批編譯發生在目錄級,而不是應用程序級。

  18. 不要依賴代碼中的異常

  因爲異常大大地降低性能,所以您不應該將它們用作控制正常程序流程的方式。如果有可能檢測到代碼中可能導致異常的狀態,請執行這種操作。不要在處理該狀態之前捕獲異常本身。常見的方案包括:檢查 null,分配給將分析爲數字值的 String 一個值,或在應用數學運算前檢查特定值。下面的示例演示可能導致異常的代碼以及測試是否存在某種狀態的代碼。兩者産生相同的結果。

  try

  {

  result = 100 / num;

  }

  catch (Exception e)

  {

  result = 0;

  }

  // ...to this.

  if (num != 0)

  result = 100 / num;

  else

  result = 0;

  19. 使用 HttpResponse.Write 方法進行字符串串聯

  該方法提供非常有效的緩沖和連接服務。但是,如果您正在執行廣泛的連接,請使用多個 Response.Write 調用。下面示例中顯示的技術比用對 Response.Write 方法的單個調用連接字符串更快。

  Response.Write("a");

  Response.Write(myString);

  Response.Write("b");

  Response.Write(myObj.ToString());

  Response.Write("c");

  Response.Write(myString2);

  Response.Write("d");

  20. 除非有特殊的原因要關閉緩沖,否則使其保持打開

  禁用 Web 窗體頁的緩沖會導致大量的性能開銷。

  21. 只在必要時保存服務器控件視圖狀態

  自動視圖狀態管理是服務器控件的功能,該功能使服務器控件可以在往返過程上重新填充它們的屬性值(您不需要編寫任何代碼)。但是,因爲服務器控件的視圖狀態在隱藏的窗體字段中往返于服務器,所以該功能確實會對性能産生影響。您應該知道在哪些情況下視圖狀態會有所幫助,在哪些情況下它影響頁的性能。例如,如果您將服務器控件綁定到每個往返過程上的數據,則將用從數據綁定操作獲得的新值替換保存的視圖狀態。在這種情況下,禁用視圖狀態可以節省處理時間。默認情況下,爲所有服務器控件啓用視圖狀態。若要禁用視圖狀態,請將控件的EnableViewState 屬性設置爲 false,如下面的 DataGrid 服務器控件示例所示。

  <asp:datagrid EnableViewState="false" datasource="..." runat="server"/>

  您還可以使用 @ Page 指令禁用整個頁的視圖狀態。當您不從頁回發到服務器時,這將十分有用:

  <%@ Page EnableViewState="false" %>

  注意:@ Control 指令中也支持 EnableViewState 屬性,該指令允許您控制是否爲用戶控件啓用視圖狀態。若要分析頁上服務器控件使用的視圖狀態的數量,請(通過將 trace="true" 屬性包括在 @ Page 指令中)啓用該頁的跟蹤並查看 Control Hierarchy 表的 Viewstate 列。有關跟蹤和如何啓用它的信息,請參見 ASP.NET 跟蹤。

  22. 避免到服務器的不必要的往返過程

  雖然您很可能希望盡量多地使用 Web 窗體頁框架的那些節省時間和代碼的功能,但在某些情況下卻不宜使用 ASP.NET 服務器控件和回發事件處理。通常,只有在檢索或存儲數據時,您才需要啓動到服務器的往返過程。多數數據操作可在這些往返過程間的客戶端上進行。例如,從 HTML 窗體驗證用戶輸入經常可在數據提交到服務器之前在客戶端進行。通常,如果不需要將信息傳遞到服務器以將其存儲在數據庫中,那麽您不應該編寫導致往返過程的代碼。如果您開發自定義服務器控件,請考慮讓它們爲支持 ECMAScript. 的浏覽器呈現客戶端代碼。通過以這種方式使用服務器控件,您可以顯著地減少信息被不必要的發送到 Web 服務器的次數。

  使用 Page.IsPostBack 避免對往返過程執行不必要的處理

  如果您編寫處理服務器控件回發處理的代碼,有時可能需要在首次請求頁時執行其他代碼,而不是當用戶發送包含在該頁中的 HTML 窗體時執行的代碼。根據該頁是否是響應服務器控件事件生成的。

  使用 Page.IsPostBack 屬性有條件地執行代碼

  例如,下面的代碼演示如何創建數據庫連接和命令,該命令在首次請求該頁時將數據綁定到 DataGrid 服務器控件。

  void Page_Load(Object sender, EventArgs e)

  {

  // Set up a connection and command here.

  if (!Page.IsPostBack)

  {

  String query = "select * from Authors where FirstName like '%JUSTIN%'";

  myCommand.Fill(ds, "Authors");

  myDataGrid.DataBind();

  }

  }

  由于每次請求時都執行 Page_Load 事件,上述代碼檢查 IsPostBack 屬性是否設置爲 false。如果是,則執行代碼。如果該屬性設置爲 true,則不執行代碼。注意 如果不運行這種檢查,回發頁的行爲將不更改。Page_Load 事件的代碼在執行服務器控件事件之前執行,但只有服務器控件事件的結果才可能在輸出頁上呈現。如果不運行該檢查,仍將爲 Page_Load 事件和該頁上的任何服務器控件事件執行處理。

  23. 當不使用會話狀態時禁用它

  並不是所有的應用程序或頁都需要針對于具體用戶的會話狀態,您應該對任何不需要會話狀態的應用程序或頁禁用會話狀態。 若要禁用頁的會話狀態,請將 @ Page 指令中的 EnableSessionState 屬性設置爲 false。例如:

  <%@ Page EnableSessi %>

  注意:如果頁需要訪問會話變量,但不打算創建或修改它們,則將@ Page 指令中的 EnableSessionState 屬性設置爲ReadOnly。還可以禁用 XML Web services 方法的會話狀態。有關更多信息,請參見使用 ASP.NET 和 XML Web services 客戶端創建的 XML Web services。若要禁用應用程序的會話狀態,請在應用程序 Web.config 文件的 sessionstate 配置節中將 mode 屬性設置爲 off。例如:

  <sessionstate mode="off" />

  24. 仔細選擇會話狀態提供程序

  ASP.NET 爲存儲應用程序的會話數據提供了三種不同的方法:進程內會話狀態、作爲 Windows 服務的進程外會話狀態和 SQL Server 數據庫中的進程外會話狀態。每種方法都有自己的優點,但進程內會話狀態是迄今爲止速度最快的解決方案。如果只在會話狀態中存儲少量易失數據,則建議您使用進程內提供程序。進程外解決方案主要用于跨多個處理器或多個計算機縮放應用程序,或者用于服務器或進程重新啓動時不能丟失數據的情況。有關更多信息,請參見 ASP.NET 狀態管理。

  25. 不使用不必要的Server Control

  ASP.net中,大量的服務器端控件方便了程序開發,但也可能帶來性能的損失,因爲用戶每操作一次服務器端控件,就産生一次與服務器端的往返過程。因此,非必要,應當少使用Server Control。

  26. ASP.NET應用程序性能測試

  在對ASP.NET應用程序進行性能測試之前,應確保應用程序沒有錯誤,而且功能正確。具體的性能測試可以采用以下工具進行:Web Application Strees Tool (WAS)是Microsoft發布的一個免費測試工具,可以從http://webtool.rte.microsoft.com/上下載。它可以模擬成百上千個用戶同時對web應用程序進行訪問請求,在服務器上形成流量負載,從而達到測試的目的,可以生成平均TTFB、平均TTLB等性能彙總報告。Application Center Test (ACT) 是一個測試工具,附帶于Visual Studio.NET的企業版中,是Microsoft正式支持的web應用程序測試工具。它能夠直觀地生成圖表結果,功能比WAS多,但不具備多個客戶機同時測試的能力。服務器操作系統"管理工具"中的"性能"計數器,可以對服務器進行監測以了解應用程序性能。

  結論:

  對于網站開發人員來說,在編寫ASP.NET應用程序時注意性能問題,養成良好的習慣,提高應用程序性能,至少可以推遲必需的硬件升級,降低網站的成本。
 
 
 
上一篇《IIS5 IIS6 IIS7的ASP.net 請求處理過程比較(1)》
下一篇《ASP.net 頁面被關閉後,服務器端是否仍然執行中?》
 
 
 
 
 
 
日版寵物情人插曲《Winding Road》歌詞

日版寵物情人2017的插曲,很帶節奏感,日語的,女生唱的。 最後聽見是在第8集的時候女主手割傷了,然後男主用嘴幫她吸了一下,插曲就出來了。 歌手:Def...

兄弟共妻,我成了他們夜裏的美食

老鍾家的兩個兒子很特別,就是跟其他的人不太一樣,魔一般的執著。兄弟倆都到了要結婚的年齡了,不管自家老爹怎麽磨破嘴皮子,兄弟倆說不娶就不娶,老父母爲兄弟兩操碎了心...

如何磨出破洞牛仔褲?牛仔褲怎麽剪破洞?

把牛仔褲磨出有線的破洞 1、具體工具就是磨腳石,下面墊一個硬物,然後用磨腳石一直磨一直磨,到把那塊磨薄了,用手撕開就好了。出來的洞啊很自然的。需要貓須的話調幾...

我就是掃描下圖得到了敬業福和愛國福

先來看下敬業福和愛國福 今年春節,支付寶再次推出了“五福紅包”活動,表示要“把欠大家的敬業福都還給大家”。 今天該活動正式啓動,和去年一樣,需要收集“五福”...

冰箱異味産生的原因和臭味去除的方法

有時候我們打開冰箱就會聞到一股異味,冰箱裏的這種異味是因爲一些物質發出的氣味的混合體,聞起來讓人惡心。 産生這些異味的主要原因有以下幾點。 1、很多人有這種習...

《極品家丁》1-31集大結局分集劇情介紹

簡介 《極品家丁》講述了現代白領林晚榮無意回到古代金陵,並追隨蕭二小姐化名“林三”進入蕭府,不料卻陰差陽錯上演了一出低級家丁拼搏上位的“林三升職記”。...

李溪芮《極品家丁》片尾曲《你就是我最愛的寶寶》歌詞

你就是我最愛的寶寶 - 李溪芮 (電視劇《極品家丁》片尾曲) 作詞:常馨內 作曲:常馨內 你的眉 又鬼馬的挑 你的嘴 又壞壞的笑 上一秒吵鬧 下...

烏梅的功效與作用以及烏梅的食用禁忌有哪些?

烏梅,又稱春梅,中醫認爲,烏梅味酸,性溫,無毒,具有安心、除熱、下氣、祛痰、止渴調中、殺蟲的功效,治肢體痛、肺痨病。烏梅泡水喝能治傷寒煩熱、止吐瀉,與幹姜一起制...

什麽是脂肪粒?如何消除臉部脂肪粒?

什麽是脂肪粒 在我們的臉上總會長一個個像脂肪的小顆粒,弄也弄不掉,而且顔色還是白白的。它既不是粉刺也不是其他的任何痘痘,它就是脂肪粒。 脂肪粒雖然也是由油脂...

網絡安全治理:國家安全保障的主要方向是打擊犯罪,而不是處置和懲罰受害者

來源:中國青年報 新的攻擊方法不斷湧現,黑客幾乎永遠占據網絡攻擊的上風,我們不可能通過技術手段杜絕網絡攻擊。國家安全保障的主要方向是打擊犯罪,而不是處置和懲罰...

河南夫妻在溫嶺網絡直播“造人”內容涉黃被刑事拘留

夫妻網絡直播“造人”爆紅   1月9日,溫嶺城北派出所接到南京警方的協查通告,他們近期打掉了一個涉黃直播APP平台。而根據掌握的線索,其中有一對涉案的夫妻主播...

如何防止牆紙老化?牆紙變舊變黃怎麽辦?

如何防止牆紙老化? (1)選擇透氣性好的牆紙 市場上牆紙的材質分無紡布的、木纖維的、PVC的、玻璃纖維基材的、布面的等,相對而言,PVC材質的牆紙最不透氣...

鮮肌之謎非日本生産VS鮮肌之謎假日貨是謠言

觀點一:破日本銷售量的“鮮肌之謎” 非日本生産 近一段時間,淘寶上架了一款名爲“鮮肌之謎的” 鲑魚卵巢美容液,號稱是最近日本的一款推出的全新護膚品,産品本身所...

中國最美古詩詞精選摘抄

系腰裙(北宋詞人 張先) 惜霜蟾照夜雲天,朦胧影、畫勾闌。人情縱似長情月,算一年年。又能得、幾番圓。 欲寄西江題葉字,流不到、五亭前。東池始有荷新綠,尚小如...

關于女人的經典語句

關于女人的經典語句1、【做一個獨立的女人】 思想獨立:有主見、有自己的人生觀、價值觀。有上進心,永遠不放棄自己的理想,做一份自己喜愛的事業,擁有快樂和成就...

未來我們可以和性愛機器人結婚嗎?

你想體驗機器人性愛嗎?你想和性愛機器人結婚嗎?如果你想,機器人有拒絕你的權利嗎? 近日,第二屆“國際人類-機器人性愛研討會”大會在倫敦金史密斯大學落下帷幕。而...

全球最變態的十個地方

10.土耳其地下洞穴城市 變態指數:★★☆☆☆ 這是土耳其卡帕多西亞的一個著名景點,傳說是當年基督教徒們爲了躲避戰爭而在此修建。裏面曾住著20000人,...

科學家稱,人類死亡後意識將在另外一個宇宙中繼續存活

據英國《每日快報》報道,一位科學家兼理論家Robert Lanza博士宣稱,世界上並不存在人類死亡,死亡的只是身體。他認爲我們的意識借助我們體內的能量生存,而且...

《屏裏狐》片頭曲《我愛狐狸精》歌詞是什麽?

《我愛狐狸精》 - 劉馨棋   (電視劇《屏裏狐》主題曲)   作詞:金十三&李旦   作曲:劉嘉   狐狸精 狐狸仙   千年修...

 
 
 
1. 數據庫訪問性能優化    數據庫的連接和關閉   訪問數據庫資源需要創建連接、打開連接和關閉連接幾個操作。這些過程需要多次與數據庫交換信息以通過身份驗證,比較耗費服務器資源。ASP.NET中提供了連接池(Connection Pool)改善打開和關閉數據庫對性能的影響。系統將用戶的數據庫連接放在連接池中,需要時取出,關閉時收回連接,等待下一次的連接請求。連接池的大小是有限的,如果在連接池達到最大限度後仍要求創建連接,必然大大影響性能。因此,在建立數據庫連接後只有在真正需要操作時才打開連接,使用完畢後馬上關閉,從而盡量減少數據庫連接打開的時間,避免出現超出連接限制的情況。      使用存儲過程    存儲過程是存儲在服務器上的一組預編譯的SQL語句,類似于DOS系統中的批處理文件。存儲過程具有對數據庫立即訪問的功能,信息處理極爲迅速。使用存儲過程可以避免對命令的多次編譯,在執行一次後其執行規劃就駐留在高速緩存中,以後需要時只需直接調用緩存中的二進制代碼即可。另外,存儲過程在服務器端運行,獨立于ASP.NET程序,便于修改,最重要的是它可以減少數據庫操作語句在網絡中的傳輸。   優化查詢語句       ASP.NET中ADO連接消耗的資源相當大,SQL語句運行的時間越長,占用系統資源的時間也越長。因此,盡量使用優化過的SQL語句以減少執行時間。比如,不在查詢語句中包含子查詢語句,充分利用索引等。      2. 字符串操作性能優化    使用值類型的ToString方法   在連接字符串時,經常使用"+"號直接將數字添加到字符串中。這種方法雖然簡單,也可以得到正確結果,但是由于涉及到不同的數據類型,數字需要通過裝箱操作轉化爲引用類型才可以添加到字符串中。但是裝箱操作對性能影響較大,因爲在進行這類處理時,將在托管堆中分配一個新的對象,原有的值複制到新創建的對象中。使用值類型的ToString方法可以避免裝箱操作,從而提高應用程序性能。      運用StringBuilder類      String類對象是不可改變的,對于String對象的重新賦值在本質上是重新創建了一個String對象並將新值賦予該對象,其方法ToString對性能的提高並非很顯著。在處理字符串時,最好使用StringBuilder類,其.NET 命名空間是System.Text。該類並非創建新的對象,而是通過Append,Remove,Insert等方法直接對字符串進行操作,通過ToString方法返回操作結果。   其定義及操作語句如下所示:   int num;   System.Text.StringBuilder str = new System.Text.StringBuilder(); //創建字符串   str.Append(num.ToString()); //添加數值num   Response.Write(str.ToString); //顯示操作結果   3. 優化 Web 服務器計算機和特定應用程序的配置文件以符合您的特定需要   默認情況下,ASP.NET 配置被設置成啓用最廣泛的功能並盡量適應最常見的方案。因此,應用程序開發人員可以根據應用程序所使用的功能,優化和更改其中的某些配置,以提高應用程序的性能。下面的列表是您應該考慮的一些選項。   僅對需要的應用程序啓用身份驗證。   默認情況下,身份驗證模式爲 Windows,或集成 NTLM。大多數情況下,對于需要身份驗證的應用程序,最好在 Machine.config 文件中禁用身份驗證,並在 Web.config 文件中啓用身份驗證。根據適當的請求和響應編碼設置來配置應用程序。ASP.NET 默認編碼格式爲 UTF-8。如果您的應用程序爲嚴格的 ASCII,請配置應用程序使用 ASCII 以獲得稍許的性能提高。   考慮對應用程序禁用 AutoEventWireup。   在 Machine.config 文件中將 AutoEventWireup 屬性設置爲 false,意味著頁面不將方法名與事件進行匹配和將兩者挂鈎(例如 Page_Load)。如果頁面開發人員要使用這些事件,需要在基類中重寫這些方法(例如,需要爲頁面加載事件重寫 Page.OnLoad,而不是使用 Page_Load 方法)。如果禁用 AutoEventWireup,頁面將通過將事件連接留給頁面作者而不是自動執行它,獲得稍許的性能提升。   從請求處理管線中移除不用的模塊。   默認情況下,服務器計算機的 Machine.config 文件中 節點的所有功能均保留爲激活。根據應用程序所使用的功能,您可以從請求管線中移除不用的模塊以獲得稍許的性能提升。檢查每個模塊及其功能,並按您的需要自定義它。例如,如果您在應用程序中不使用會話狀態和輸出緩存,則可以從 列表中移除它們,以便請求在不執行其他有意義的處理時,不必執行每個模塊的進入和離開代碼。   4. 一定要禁用調試模式     在部署生産應用程序或進行任何性能測量之前,始終記住禁用調試模式。如果啓用了調試模式,應用程序的性能可能受到非常大的影響。      5. 對于廣泛依賴外部資源的應用程序,請考慮在多處理器計算機上啓用網絡園藝     ASP.NET 進程模型幫助啓用多處理器計算機上的可縮放性,將工作分發給多個進程(每個CPU一個),並且每個進程都將處理器關系設置爲其 CPU。此技術稱爲網絡園藝。如果應用程序使用較慢的數據庫服務器或調用具有外部依賴項的 COM 對象(這裏只是提及兩種可能性),則爲您的應用程序啓用網絡園藝是有益的。但是,在決定啓用網絡園藝之前,您應該測試應用程序在網絡園中的執行情況。      6. 只要可能,就緩存數據和頁輸出     ASP.NET 提供了一些簡單的機制,它們會在不需要爲每個頁請求動態計算頁輸出或數據時緩存這些頁輸出或數據。另外,通過設計要進行緩存的頁和數據請求(特別是在站點中預期將有較大通訊量的區域),可以優化這些頁的性能。與 .NET Framework 的任何 Web 窗體功能相比,適當地使用緩存可以更好的提高站點的性能,有時這種提高是超數量級的。使用 ASP.NET 緩存機制有兩點需要注意。首先,不要緩存太多項。緩存每個項均有開銷,特別是在內存使用方面。不要緩存容易重新計算和很少使用的項。其次,給緩存的項分配的有效期不要太短。很快到期的項會導致緩存中不必要的周轉,並且經常導致更多的代碼清除和垃圾回收工作。若關心此問題,請監視與 ASP.NET Applications 性能對象關聯的 Cache Total Turnover Rate 性能計數器。高周轉率可能說明存在問題,特別是當項在到期前被移除時。這也稱作內存壓力。   7. 選擇適合頁面或應用程序的數據查看機制     根據您選擇在 Web 窗體頁顯示數據的方式,在便利和性能之間常常存在著重要的權衡。例如,DataGrid Web 服務器控件可能是一種顯示數據的方便快捷的方法,但就性能而言它的開銷常常是最大的。在某些簡單的情況下,您通過生成適當的 HTML 自己呈現數據可能很有效,但是自定義和浏覽器定向會很快抵銷所獲得的額外功效。Repeater Web 服務器控件是便利和性能的折衷。它高效、可自定義且可編程。      8. 將 SqlDataReader 類用于快速只進數據遊標     SqlDataReader 類提供了一種讀取從 SQL Server 數據庫檢索的只進數據流的方法。如果當創建 ASP.NET 應用程序時出現允許您使用它的情況,則 SqlDataReader 類提供比 DataSet 類更高的性能。情況之所以這樣,是因爲 SqlDataReader 使用 SQL Server 的本機網絡數據傳輸格式從數據庫連接直接讀取數據。另外,SqlDataReader 類實現 IEnumerable 接口,該接口也允許您將數據綁定到服務器控件。有關更多信息,請參見 SqlDataReader 類。有關 ASP.NET 如何訪問數據的信息,請參見通過 ASP.NET 訪問數據。      9. 將 SQL Server 存儲過程用于數據訪問     在 .NET Framework 提供的所有數據訪問方法中,基于 SQL Server 的數據訪問是生成高性能、可縮放 Web 應用程序的推薦選擇。使用托管 SQL Server 提供程序時,可通過使用編譯的存儲過程而不是特殊查詢獲得額外的性能提高。      10. 避免單線程單元 (STA) COM 組件     默認情況下,ASP.NET 不允許任何 STA COM 組件在頁面內運行。若要運行它們,必須在 .aspx 文件內將 ASPCompat=true 屬性包含在 @ Page 指令中。這樣就將執行用的線程池切換到 STA 線程池,而且使 HttpContext 和其他內置對象可用于 COM 對象。前者也是一種性能優化,因爲它避免了將多線程單元 (MTA) 封送到 STA 線程的任何調用。使用 STA COM 組件可能大大損害性能,應盡量避免。若必須使用 STA COM 組件,如在任何 interop 方案中,則應在執行期間進行大量調用並在每次調用期間發送盡可能多的信息。另外,小心不要在構造頁面期間創建任何 STA COM 組件。例如下面的代碼中,在頁面構造時將實例化由某個線程創建的 MySTAComponent,而該線程並不是將運行頁面的 STA 線程。這可能對性能有不利影響,因爲要構造頁面就必須完成 MTA 和 STA 線程之間的封送處理。   <%@ Page Language="VB" ASPCompat="true" %>   <script. runat=server>   Dim myComp as new MySTAComponent()   Public Sub Page_Load()   myComp.Name = "Bob"   End Sub   </script>   <html>   <% Response.Write(myComp.SayHello) %>  Response.Write(myComp.SayHello)   %>   </html>   首選機制是推遲對象的創建,直到以後在 STA 線程下執行上述代碼,如下面的例子所示。   <%@ Page Language="VB" ASPCompat="true" %>   <script. runat=server>   Dim myComp   Public Sub Page_Load()   myComp = new MySTAComponent()   myComp.Name = "Bob"   End Sub   </script>   <html>   <% Response.Write(myComp.SayHello) %>  Response.Write(myComp.SayHello)   %>   </html>   推薦的做法是在需要時或者在 Page_Load 方法中構造任何 COM 組件和外部資源。永遠不要將任何 STA COM 組件存儲在可以由構造它的線程以外的其他線程訪問的共享資源裏。這類資源包括像緩存和會話狀態這樣的資源。即使 STA 線程調用 STA COM 組件,也只有構造此 STA COM 組件的線程能夠實際爲該調用服務,而這要求封送處理對創建者線程的調用。此封送處理可能産生重大的性能損失和可伸縮性問題。在這種情況下,請研究一下使 COM 組件成爲 MTA COM 組件的可能性,或者更好的辦法是遷移代碼以使對象成爲托管對象。      11. 將調用密集型的 COM 組件遷移到托管代碼     .NET Framework 提供了一個簡單的方法與傳統的 COM 組件進行交互。其優點是可以在保留現有投資的同時利用新的平台。但是在某些情況下,保留舊組件的性能開銷使得將組件遷移到托管代碼是值得的。每一情況都是不一樣的,決定是否需要遷移組件的最好方法是對 Web 站點運行性能測量。建議您研究一下如何將需要大量調用以進行交互的任何COM 組件遷移到托管代碼。許多情況下不可能將舊式組件遷移到托管代碼,特別是在最初遷移 Web 應用程序時。在這種情況下,最大的性能障礙之一是將數據從非托管環境封送到托管環境。因此,在交互操作中,請在任何一端執行盡可能多的任務,然後進行一個大調用而不是一系列小調用。例如,公共語言運行庫中的所有字符串都是 Unicode 的,所以應在調用托管代碼之前將組件中的所有字符串轉換成 Unicode 格式。另外,一處理完任何 COM 對象或本機資源就釋放它們。這樣,其他請求就能夠使用它們,並且最大限度地減少了因稍後請求垃圾回收器釋放它們所引起的性能問題。      12. 在 Visual Basic .NET 或 JScript. 代碼中使用早期綁定     以往,開發人員喜歡使用 Visual Basic、VBScript. 和 JScript. 的原因之一就是它們所謂「無類型」的性質。變量不需要顯式類型聲明,並能夠簡單地通過使用來創建它們。當從一個類型到另一個類型進行分配時,轉換將自動執行。不過,這種便利會大大損害應用程序的性能。Visual Basic 現在通過使用 Option Strict 編譯器指令來支持類型安全編程。爲了向後兼容,默認情況下,ASP.NET 不啓用該選項。但是,爲了得到最佳性能,強烈建議在頁中啓用該選項。若要啓用 Option Strict,請將 Strict 屬性包括在 @ Page 指令中,或者,對于用戶控件,請將該屬性包括在 @ Control 指令中。下面的示例演示了如何設置該屬性,並進行了四個變量調用以顯示使用該屬性是如何導致編譯器錯誤的。   <%@ Page Language="VB" Strict="true" %>   <% Dim B Dim C As String ' This will cause a compiler error. A = "Hello" ' This will cause a compiler error. B = "World" ' This will not cause a compiler error. C = "!!!!!!" ' But this will cause a compiler error. C = 0 %>  Dim B   Dim C As String   ' This will cause a compiler error.   A = "Hello"   ' This will cause a compiler error.   B = "World"   ' This will not cause a compiler error.   C = "!!!!!!"   ' But this will cause a compiler error.   C = 0   %> JScript. .NET 也支持無類型編程,但它不提供強制早期綁定的編譯器指令。若發生下面任何一種情況,則變量是晚期綁定的:被顯式聲明爲 Object,是無類型聲明的類的字段,是無顯式類型聲明的專用函數或方法成員,並且無法從其使用推斷出類型。   最後一個差別比較複雜,因爲如果 JScript. .NET 編譯器可以根據變量的使用情況推斷出類型,它就會進行優化。在下面的示例中,變量 A 是早期綁定的,但變量 B 是晚期綁定的。   var A;   var B;   A = "Hello";   B = "World";   B = 0; 爲了獲得最佳的性能,當聲明 JScript. .NET 變量時,請爲其分配一個類型。例如,var A : String。   13. 使請求管線內的所有模塊盡可能高效     請求管線內的所有模塊在每次請求中都有機會被運行。因此,當請求進入和離開模塊時快速地觸發代碼至關重要,特別是在不使用模塊功能的代碼路徑裏。分別在使用及不使用模塊和配置文件時執行吞吐量測試,對確定這些方法的執行速度非常有用。   14. 使用 HttpServerUtility.Transfer 方法在同一應用程序的頁面間重定向     采用 Server.Transfer 語法,在頁面中使用該方法可避免不必要的客戶端重定向。   15. 必要時調整應用程序每個輔助進程的線程數     ASP.NET 的請求結構試圖在執行請求的線程數和可用資源之間達到一種平衡。已知一個使用足夠 CPU 功率的應用程序,該結構將根據可用于請求的 CPU 功率,來決定允許同時執行的請求數。這項技術稱作線程門控。但是在某些條件下,線程門控算法不是很有效。通過使用與 ASP.NET Applications 性能對象關聯的 Pipeline Instance Count 性能計數器,可以在 PerfMon 中監視線程門控。當頁面調用外部資源,如數據庫訪問或 XML Web services 請求時,頁面請求通常停止並釋放 CPU。如果某個請求正在等待被處理,並且線程池中有一個線程是自由的,那麽這個正在等待的請求將開始被處理。遺憾的是,有時這可能導致 Web 服務器上存在大量同時處理的請求和許多正在等待的線程,而它們對服務器性能有不利影響。通常,如果門控因子是外部資源的響應時間,則讓過多請求等待資源,對 Web 服務器的吞吐量並無幫助。爲緩和這種情況,可以通過更改 Machine.config 配置文件節點的 maxWorkerThreads 和 maxIOThreads 屬性,手動設置進程中的線程數限制。      注意:輔助線程是用來處理 ASP.NET 請求的,而 IO 線程則是用于爲來自文件、數據庫或 XML Web services 的數據提供服務的。分配給這些屬性的值是進程中每個 CPU 每類線程的最大數目。對于雙處理器計算機,最大數是設置值的兩倍。對于四處理器計算機,最大值是設置值的四倍。無論如何,對于有四個或八個 CPU 的計算機,最好更改默認值。對于有一個或兩個處理器的計算機,默認值就可以,但對于有更多處理器的計算機的性能,進程中有一百或兩百個線程則弊大于利。注意進程中有太多線程往往會降低服務器的速度,因爲額外的上下文交換導致操作系統將 CPU 周期花在維護線程而不是處理請求上。      16. 適當地使用公共語言運行庫的垃圾回收器和自動內存管理     小心不要給每個請求分配過多內存,因爲這樣垃圾回收器將必須更頻繁地進行更多的工作。另外,不要讓不必要的指針指向對象,因爲它們將使對象保持活動狀態,並且應盡量避免含 Finalize 方法的對象,因爲它們在後面會導致更多的工作。特別是在 Finalize 調用中永遠不要釋放資源,因爲資源在被垃圾回收器回收之前可能一直消耗著內存。最後這個問題經常會對 Web 服務器環境的性能造成毀滅性的打擊,因爲在等待 Finalize 運行時,很容易耗盡某個特定的資源。      17. 如果有大型 Web 應用程序,可考慮執行預批編譯     每當發生對目錄的第一次請求時都會執行批編譯。如果目錄中的頁面沒有被分析並編譯,此功能會成批分析並編譯目錄中的所有頁面,以便更好地利用磁盤和內存。如果這需要很長時間,則將快速分析並編譯單個頁面,以便請求能被處理。此功能帶給 ASP.NET 性能上的好處,因爲它將許多頁面編譯爲單個程序集。從已加載的程序集訪問一頁比每頁加載新的程序集要快。批編譯的缺點在于:如果服務器接收到許多對尚未編譯的頁面的請求,那麽當 Web 服務器分析並編譯它們時,性能可能較差。爲解決這個問題,可以執行預批編譯。爲此,只需在應用程序激活之前向它請求一個頁面,無論哪頁均可。然後,當用戶首次訪問您的站點時,頁面及其程序集將已被編譯。沒有簡單的機制可以知道批編譯何時發生。需一直等到 CPU 空閑或者沒有更多的編譯器進程(例如 csc.exe(C# 編譯器)或 vbc.exe(Visual Basic 編譯器))啓動。還應盡量避免更改應用程序的 bin 目錄中的程序集。更改頁面會導致重新分析和編譯該頁,而替換 bin 目錄中的程序集則會導致完全重新批編譯該目錄。在包含許多頁面的大規模站點上,更好的辦法可能是根據計劃替換頁面或程序集的頻繁程度來設計不同的目錄結構。不常更改的頁面可以存儲在同一目錄中並在特定的時間進行預批編譯。經常更改的頁面應在它們自己的目錄中(每個目錄最多幾百頁)以便快速編譯。Web 應用程序可以包含許多子目錄。批編譯發生在目錄級,而不是應用程序級。   18. 不要依賴代碼中的異常     因爲異常大大地降低性能,所以您不應該將它們用作控制正常程序流程的方式。如果有可能檢測到代碼中可能導致異常的狀態,請執行這種操作。不要在處理該狀態之前捕獲異常本身。常見的方案包括:檢查 null,分配給將分析爲數字值的 String 一個值,或在應用數學運算前檢查特定值。下面的示例演示可能導致異常的代碼以及測試是否存在某種狀態的代碼。兩者産生相同的結果。   try   {   result = 100 / num;   }   catch (Exception e)   {   result = 0;   }   // ...to this.   if (num != 0)   result = 100 / num;   else   result = 0;   19. 使用 HttpResponse.Write 方法進行字符串串聯   該方法提供非常有效的緩沖和連接服務。但是,如果您正在執行廣泛的連接,請使用多個 Response.Write 調用。下面示例中顯示的技術比用對 Response.Write 方法的單個調用連接字符串更快。   Response.Write("a");   Response.Write(myString);   Response.Write("b");   Response.Write(myObj.ToString());   Response.Write("c");   Response.Write(myString2);   Response.Write("d");   20. 除非有特殊的原因要關閉緩沖,否則使其保持打開   禁用 Web 窗體頁的緩沖會導致大量的性能開銷。      21. 只在必要時保存服務器控件視圖狀態     自動視圖狀態管理是服務器控件的功能,該功能使服務器控件可以在往返過程上重新填充它們的屬性值(您不需要編寫任何代碼)。但是,因爲服務器控件的視圖狀態在隱藏的窗體字段中往返于服務器,所以該功能確實會對性能産生影響。您應該知道在哪些情況下視圖狀態會有所幫助,在哪些情況下它影響頁的性能。例如,如果您將服務器控件綁定到每個往返過程上的數據,則將用從數據綁定操作獲得的新值替換保存的視圖狀態。在這種情況下,禁用視圖狀態可以節省處理時間。默認情況下,爲所有服務器控件啓用視圖狀態。若要禁用視圖狀態,請將控件的EnableViewState 屬性設置爲 false,如下面的 DataGrid 服務器控件示例所示。   <asp:datagrid EnableViewState="false" datasource="..." runat="server"/>   您還可以使用 @ Page 指令禁用整個頁的視圖狀態。當您不從頁回發到服務器時,這將十分有用:   <%@ Page EnableViewState="false" %>   注意:@ Control 指令中也支持 EnableViewState 屬性,該指令允許您控制是否爲用戶控件啓用視圖狀態。若要分析頁上服務器控件使用的視圖狀態的數量,請(通過將 trace="true" 屬性包括在 @ Page 指令中)啓用該頁的跟蹤並查看 Control Hierarchy 表的 Viewstate 列。有關跟蹤和如何啓用它的信息,請參見 ASP.NET 跟蹤。   22. 避免到服務器的不必要的往返過程     雖然您很可能希望盡量多地使用 Web 窗體頁框架的那些節省時間和代碼的功能,但在某些情況下卻不宜使用 ASP.NET 服務器控件和回發事件處理。通常,只有在檢索或存儲數據時,您才需要啓動到服務器的往返過程。多數數據操作可在這些往返過程間的客戶端上進行。例如,從 HTML 窗體驗證用戶輸入經常可在數據提交到服務器之前在客戶端進行。通常,如果不需要將信息傳遞到服務器以將其存儲在數據庫中,那麽您不應該編寫導致往返過程的代碼。如果您開發自定義服務器控件,請考慮讓它們爲支持 ECMAScript. 的浏覽器呈現客戶端代碼。通過以這種方式使用服務器控件,您可以顯著地減少信息被不必要的發送到 Web 服務器的次數。   使用 Page.IsPostBack 避免對往返過程執行不必要的處理   如果您編寫處理服務器控件回發處理的代碼,有時可能需要在首次請求頁時執行其他代碼,而不是當用戶發送包含在該頁中的 HTML 窗體時執行的代碼。根據該頁是否是響應服務器控件事件生成的。   使用 Page.IsPostBack 屬性有條件地執行代碼   例如,下面的代碼演示如何創建數據庫連接和命令,該命令在首次請求該頁時將數據綁定到 DataGrid 服務器控件。   void Page_Load(Object sender, EventArgs e)   {   // Set up a connection and command here.   if (!Page.IsPostBack)   {   String query = "select * from Authors where FirstName like '%JUSTIN%'";   myCommand.Fill(ds, "Authors");   myDataGrid.DataBind();   }   }   由于每次請求時都執行 Page_Load 事件,上述代碼檢查 IsPostBack 屬性是否設置爲 false。如果是,則執行代碼。如果該屬性設置爲 true,則不執行代碼。注意 如果不運行這種檢查,回發頁的行爲將不更改。Page_Load 事件的代碼在執行服務器控件事件之前執行,但只有服務器控件事件的結果才可能在輸出頁上呈現。如果不運行該檢查,仍將爲 Page_Load 事件和該頁上的任何服務器控件事件執行處理。      23. 當不使用會話狀態時禁用它     並不是所有的應用程序或頁都需要針對于具體用戶的會話狀態,您應該對任何不需要會話狀態的應用程序或頁禁用會話狀態。   若要禁用頁的會話狀態,請將 @ Page 指令中的 EnableSessionState 屬性設置爲 false。例如:   <%@ Page EnableSessi %>   注意:如果頁需要訪問會話變量,但不打算創建或修改它們,則將@ Page 指令中的 EnableSessionState 屬性設置爲ReadOnly。還可以禁用 XML Web services 方法的會話狀態。有關更多信息,請參見使用 ASP.NET 和 XML Web services 客戶端創建的 XML Web services。若要禁用應用程序的會話狀態,請在應用程序 Web.config 文件的 sessionstate 配置節中將 mode 屬性設置爲 off。例如:   <sessionstate mode="off" />   24. 仔細選擇會話狀態提供程序     ASP.NET 爲存儲應用程序的會話數據提供了三種不同的方法:進程內會話狀態、作爲 Windows 服務的進程外會話狀態和 SQL Server 數據庫中的進程外會話狀態。每種方法都有自己的優點,但進程內會話狀態是迄今爲止速度最快的解決方案。如果只在會話狀態中存儲少量易失數據,則建議您使用進程內提供程序。進程外解決方案主要用于跨多個處理器或多個計算機縮放應用程序,或者用于服務器或進程重新啓動時不能丟失數據的情況。有關更多信息,請參見 ASP.NET 狀態管理。      25. 不使用不必要的Server Control   ASP.net中,大量的服務器端控件方便了程序開發,但也可能帶來性能的損失,因爲用戶每操作一次服務器端控件,就産生一次與服務器端的往返過程。因此,非必要,應當少使用Server Control。      26. ASP.NET應用程序性能測試     在對ASP.NET應用程序進行性能測試之前,應確保應用程序沒有錯誤,而且功能正確。具體的性能測試可以采用以下工具進行:Web Application Strees Tool (WAS)是Microsoft發布的一個免費測試工具,可以從[url=http://webtool.rte.microsoft.com/]http://webtool.rte.microsoft.com/[/url]上下載。它可以模擬成百上千個用戶同時對web應用程序進行訪問請求,在服務器上形成流量負載,從而達到測試的目的,可以生成平均TTFB、平均TTLB等性能彙總報告。Application Center Test (ACT) 是一個測試工具,附帶于Visual Studio.NET的企業版中,是Microsoft正式支持的web應用程序測試工具。它能夠直觀地生成圖表結果,功能比WAS多,但不具備多個客戶機同時測試的能力。服務器操作系統"管理工具"中的"性能"計數器,可以對服務器進行監測以了解應用程序性能。      結論:   對于網站開發人員來說,在編寫ASP.NET應用程序時注意性能問題,養成良好的習慣,提高應用程序性能,至少可以推遲必需的硬件升級,降低網站的成本。
󰈣󰈤
 
 
 
  免責聲明:本文僅代表作者個人觀點,與王朝網路無關。王朝網路登載此文出於傳遞更多信息之目的,並不意味著贊同其觀點或證實其描述,其原創性以及文中陳述文字和內容未經本站證實,對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾,請讀者僅作參考,並請自行核實相關內容。
 
 
寶貝清純百變豬豬
美女喜太狼裙裝時代
美麗幹練的OL
平面模特楊棋涵
石系列印象
海洲錦屏磷礦
再憶桂林
觀:重金屬所攝影:元陽梯田所想
 
>>返回首頁<<
 
 
 
 熱帖排行
 
 
 
 
© 2005- 王朝網路 版權所有