您現(xiàn)在的位置： 365建站網(wǎng) > 365文章 > asp.net 性能調(diào)較

asp.net 性能調(diào)較

文章來源：365jz.com 點擊數(shù)：150 更新時間：2009-09-16 11:56 參與評論

由于asp.net 處理進程在machine.config配置文件中的配置為<processModel autoConfig="true" />，這意味著你的asp.net 應(yīng)用程序使用的性能參數(shù)依賴于machine.config的配置。
下面幾個參數(shù)是自動配置的：

maxWorkerThreads 和 maxIoThreads
minFreeThreads 和 minLocalRequestFreeThreads
minWorkerThreads
maxconnection
executionTimeout

這幾個參數(shù)會和你的應(yīng)用程序發(fā)生這樣的癥狀相關(guān)“爭用、性能下降和死鎖進行 Web 服務(wù)請求從 ASP.NET 應(yīng)用程序時”：

進行從 ASP.NET 應(yīng)用程序, 調(diào)用 XMLWeb 服務(wù)時可能會遇到爭用、性能下降和死鎖。客戶可能報告請求停止響應(yīng) （或 " 掛起 "）或需要很長時間來執(zhí)行。如果懷疑死, 可能回收輔助進程。應(yīng)用程序事件日志中可能會收到以下消息。 • 如果您使用 MicrosoftInternet 信息服務(wù) (IIS) 5.0, 會應(yīng)用程序事件日志中您收到以下消息：

   Event Type:     Error
   Event Source:   ASP.NET 1.0.3705.0
   Event Category: None
   Event ID:       1003
   Date:           5/4/2003
   Time:           6:18:23 PM
   User:           N/A
   Computer:       <ComputerName>
   Description:
      aspnet_wp.exe (PID: <xxx>) was recycled because it was suspected to be in a deadlocked state.
      It did not send any responses for pending requests in the last 180 seconds.

• 如果您使用 IIS 6.0, 會應(yīng)用程序事件日志中您收到以下消息：

   Event Type:     Warning
   Event Source:   W3SVC-WP
   Event Category: None
   Event ID:       2262
   Date:           5/4/2003
   Time:           1:02:33 PM
   User:           N/A
   Computer:       <ComputerName>
   Description:
      ISAPI 'C:\Windows\Microsoft.net\Framework\v.1.1.4322\aspnet_isapi.dll' reported itself as
      unhealthy for the following reason: 'Deadlock detected'.

• 如果您使用 IIS 6.0, 會系統(tǒng)事件日志中您收到以下消息：

   Event Type:     Warning
   Event Source:   W3SVC
   Event Category: None
   Event ID:       1013
   Date:           5/4/2003
   Time:           1:03:47 PM
   User:           N/A
   Computer:       <ComputerName>
   Description:
      A process serving application pool 'DefaultAppPool' exceeded time limits during shut down.
      The process id was '<xxxx>'.

可能會進行對 HttpWebRequest.GetResponse 方法調(diào)用時還收到以下異常錯誤信息：
ôSystem.InvalidOperationException 有是沒有足夠的空閑線程 ThreadPool 對象以完成 operation.ö 中：
還可能在瀏覽器收到以下異常錯誤信息：
請求定時 out.ö ôHttpException (0 x 80004005)：
注意本文還適用于應(yīng)用程序直接使 HttpWebRequest 請求。

原因

因為 ASP.NET 的輔助線程和完成端口線程，調(diào)用可用于執(zhí)行請求數(shù)限制可能發(fā)生此問題。

對 Web 服務(wù)調(diào)用通常, 使用一個輔助線程來執(zhí)行代碼發(fā)送請求和一個完成端口線程以從 Web 服務(wù)接收回調(diào)。但是, 如果請求重定向或需要驗證, 調(diào)用可能使用多達兩輔助和兩完成端口線程。同時發(fā)生多個 Web 服務(wù)調(diào)用時, 因此您可消耗托管 ThreadPool。

例如, 假設(shè) ThreadPool 僅限于 maxworkerthreads, 10，并且當(dāng)前執(zhí)行所有 10 工作線程正在等待回調(diào)來執(zhí)行代碼。由于工作項排隊以 ThreadPool 阻塞線程可用之前可從不執(zhí)行回調(diào)。

其他潛在源爭奪是 maxconnection 參數(shù)， System.Net 命名空間用于限制的連接數(shù)。此限制通常, 按預(yù)期工作。但是, 如果許多應(yīng)用程序嘗試使許多請求到單個 IP 地址同時, 線程可能需要等待一個可用連接。

解決方案
Machine.config 文件以最適合您情況中要解決這些問題, 可調(diào)整以下參數(shù)： • maxWorkerThreads
• minWorkerThreads
• maxIoThreads
• minFreeThreads
• minLocalRequestFreeThreads
• maxconnection
• executionTimeout
要成功解決這些問題, 請按照下列步驟操作： • 限制同時到大約 12 每 CPU 執(zhí)行， ASP.NET 請求的數(shù)量。
• 允許 Web 服務(wù)回調(diào)用于 ThreadPool 中自由線程。
• 選擇一個適當(dāng)值對于 maxconnections 參數(shù)。根據(jù)您選擇的 IP 地址和 AppDomains 使用數(shù)。
注意：建議來限制每 CPU 12 ASP.NET 請求的數(shù)量是有點任意。但是, 此限制已證明能夠適合大多數(shù)應(yīng)用程序。

具體參見：http://support.microsoft.com/Default.aspx?id=821268

作者: 自由、創(chuàng)新、研究、探索……
出處：http://shanyou.cnblogs.com/
版權(quán)：本文版權(quán)歸作者和博客園共有
轉(zhuǎn)載：歡迎轉(zhuǎn)載，為了保存作者的創(chuàng)作熱情，請按要求【轉(zhuǎn)載】，謝謝
要求：未經(jīng)作者同意，必須保留此段聲明；必須在文章中給出原文連接；否則必究法律責(zé)任
個人網(wǎng)站: http://www.openbeta.cn/