爭用、 效能不佳、 和死結 (deadlock) 當您從 ASP.NET 應用程式呼叫 Web 服務

文章翻譯 文章翻譯
文章編號: 821268 - 檢視此文章適用的產品。
全部展開 | 全部摺疊

在此頁中

徵狀

當您從 Microsoft 的 ASP.NET 應用程式呼叫 Web 服務,您可能會發生爭用、 效能不佳、 和死結 (deadlock)。要求停止回應 (或 「 擱置 」),或花很長的時間來執行,可能會通知用戶端。如果懷疑死結,則可能會回收工作者處理序。您可能會收到下列訊息的應用程式事件日誌中。
  • 如果您正在使用網際網路資訊服務 (IIS) 5.0,您會收到下列訊息,應用程式日誌中:

       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,您會收到下列訊息,應用程式日誌中:

       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,您將在系統記錄檔中收到下列訊息:

       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方法:
「 System.InvalidOperationException:若要完成的執行緒集區物件中沒有足夠的無限制執行緒操作。"
您也可能會收到下列的例外狀況錯誤訊息在瀏覽器中:
"HttpException (0x80004005): 要求逾時伸。 」
附註這篇文章也適用於直接進行HttpWebRequest要求的應用程式中。

發生的原因

這個問題可能是因為 ASP.NET 會限制數目背景工作執行緒與完成通訊埠執行緒的呼叫可以用來執行要求。

通常,Web 服務的呼叫會使用一個背景工作執行緒,來執行的程式碼,將要求傳送和接收回呼,從 Web 服務的一個完成通訊埠執行緒。不過,如果要求重新導向,或需要驗證,呼叫可能會使用最多兩個背景工作執行緒和兩個完成通訊埠執行緒。因此,您可以在多個 Web 服務呼叫發生在同一時間時,耗盡 managed 執行緒集區。

比方說,假設執行緒集區限制為 10 個背景工作執行緒,而且所有 10 個工作者執行緒目前正在執行的程式碼,正在等待要執行的回呼。回呼可以永遠不會執行,因為任何均佇列至執行緒集區的工作項目被封鎖,直到執行緒變成可用。

另一個的潛在來源是爭用的maxconnection參數System.Net命名空間用來限制連線數目。一般而言,這項限制的運作方式如預期般運作。不過,如果許多應用程式正試圖執行許多同時在同一個特定 IP 位址的要求,執行緒可能需要等待可用的連線。

解決方案

若要解決這些問題,您可以調整下列參數中 Machine.config 檔,以最適合您的情況:
  • maxWorkerThreads
  • minWorkerThreads
  • maxIoThreads
  • minFreeThreads
  • minLocalRequestFreeThreads
  • maxconnection
  • executionTimeout
若要成功解決這些問題,請採取下列動作:
  • 限制在可執行的 ASP.NET 要求數目大約每個 CPU 的十二個相同的時間。
  • 允許自由使用執行緒集區中的 [執行緒的 Web 服務回呼。
  • 選取適當的值為maxconnections參數。您選取的項目所依據的 IP 位址數目,所使用的 Appdomain。
附註若要限制到 12 的 ASP.NET 要求數目建議每個 CPU 是有點任意項目。不過,這項限制也已經證明不適用於大部分的應用程式。

maxWorkerThreadsmaxIoThreads

ASP.NET 會使用下列兩個組態設定若要限制的背景工作執行緒與完成執行緒的數目上限使用此項目:
<processModel maxWorkerThreads="20" maxIoThreads="20">
MaxWorkerThreads參數及maxIoThreads參數隱含會乘 Cpu 數目。針對範例中,如果您有兩個處理器,背景工作執行緒的最大數目是下列步驟:
2 * maxWorkerThreads

minFreeThreadsminLocalRequestFreeThreads

ASP.NET 也會包含下列的設定設定可決定多少的背景工作執行緒與完成通訊埠執行緒必須是可用來啟動遠端的要求或用於本機要求:
<httpRuntime minFreeThreads="8" minLocalRequestFreeThreads="8">
如果沒有足夠的執行緒可用,要求會排入佇列直到足夠的執行緒可以執行要求。因此,ASP.NET 會不會執行下列的要求數目超過一次:
(maxWorkerThreads*Cpu 數目)-minFreeThreads
附註MinFreeThreads參數及minLocalRequestFreeThreads參數會不隱含乘 Cpu 數目。

minWorkerThreads

正如 ASP.NET 1.0 的 Service Pack 3 和 ASP.NET 1.1 中,ASP.NET 也會包含下列的組態設定,決定如何多個背景工作執行緒可以由可以立即服務遠端要求。
<processModel minWorkerThreads="1">
執行緒控制這個設定可以加快速度比建立從 CLR 的預設 「 執行緒調整 」 所建立的背景工作執行緒功能。這個設定會啟用 ASP.NET 要求提供服務的作品,突然填滿 ASP.NET 要求佇列,因為在後端的 slow-down伺服器上,突然出現的尖峰處理的從用戶端結束時,或類似的要求會使得突然上升的要求數目在佇列中。[minWorkerThreads參數的預設值為 1。我們建議您將minWorkerThreads參數的值設定為下列值。
minWorkerThreads = maxWorkerThreads / 2
預設情況下, minWorkerThreads參數不是在 Web.config 檔案或Machine.config 檔中。這項設定會隱含乘以數量Cpu。

maxconnection

Maxconnection參數會決定多少會連接到特定的 IP 位址。參數如下所示:
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://65.53.32.230" maxconnection="12">
</connectionManagement>
如果應用程式的程式碼會參考應用程式的主機名稱,而不是 IP 位址,此參數應該會出現,如下所示:
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://hostname" maxconnection="12">
</connectionManagement>
最後,如果應用程式裝載在 80 埠以外,這些參數必須納入的 URI,類似下列的非標準的連接埠:
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://hostname:8080" maxconnection="12">
</connectionManagement>
本文稍早所討論的參數值為處理序層級的所有項目。不過, maxconnection參數設定會套用到 AppDomain 層級。根據預設,由於這項設定會套用到 AppDomain 層級中,您可以建立最大值兩個連線到特定的 IP 位址在每一個 AppDomain 從您處理程序。

executionTimeout

ASP.NET 會使用下列的組態設定,來限制要求的執行時間:
<httpRuntime executionTimeout="90"/>
您也可以使用Server.ScriptTimeout屬性來設定此限制。

附註如果您增加executionTimeout參數的值時,您可能也必須修改processModelresponseDeadlockInterval參數設定。

建議

這一節中所建議的設定值可能不適用於所有的應用程式。不過,下列的額外資訊可以協助您進行適當的調整。

如果當您建立一個 Web 服務呼叫到單一的 IP 位址在每個 ASPX 頁面上,Microsoft 建議您,使用下列組態設定:
  • 您可以設定maxWorkerThreads參數和maxIoThreads參數的值為100
  • 設定的maxconnection參數的值 12 *N (其中 N 是 Cpu 的數目,您需要)。
  • 設定的minFreeThreads參數的值 88 *NminLocalRequestFreeThreads參數76 *N.
  • 設定minWorkerThreads為 50的值。請記住, minWorkerThreads不是預設的組態檔中。您必須將它加入。
某些這些建議可以在牽涉到簡單的公式包含數字伺服器上的 Cpu。表示在 Cpu 數目的變數公式是 N.這些設定,如果您有啟用超執行緒您必須使用邏輯的 Cpu 數目,而不是實體的 Cpu 數目。比方說,如果啟用了超執行緒中有四個處理器的伺服器值 N 在公式中為8 ,而不是4

附註當您使用這項設定時,您就可以執行最多 12 個ASP.NET 要求每個 CPU 同時因為100 88 = 12。因此,至少 88 *N 背景工作執行緒和 88 *N 完成通訊埠執行緒是可供其他使用 (比如 Web 服務的回呼)。

比方說,您必須具有四個處理器和超執行緒的伺服器啟用此項目。根據這些公式,您可以使用下列值這份文件中所提及的設定值。
<system.web>
	<processModel maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50"/>
	<httpRuntime minFreeThreads="704" minLocalRequestFreeThreads="608"/>
</system.web>

<system.net>
	<connectionManagement>
		<add address="[ProvideIPHere]" maxconnection="96"/>
	</connectionManagement>
</system.net>

此外,當您使用這項設定,12 可用的連接時每個 CPU,每一個 IP 位址的每一個 AppDomain。因此,在下列式子案例中,很少的爭用會發生於要求等待連接和執行緒集區已不會用完:
  • Web 裝載只能有一個應用程式 (AppDomain)。
  • 每個要求的 ASPX 頁面可讓一個 Web 服務要求。
  • 所有的要求是以相同的 IP 位址。
不過,當您使用這項設定時,情節,涉及下列其中一項可能會使用太多連線:
  • 要求的多個 IP 位址。
  • 要求會重新導向 (302 狀態碼)。
  • 要求需要驗證。
  • 從多個的 Appdomain 發出要求。
在這些情況下,最好使用較低的值,如maxconnection參數與較高的minFreeThreads參數和minLocalRequestFreeThreads參數的值。

狀況說明

這行為是經過設計規劃。

其他相關資訊

如果您遇到效能不佳、 以及 ASP.NET 的 IIS 7.0 中的競爭,前往下列 Microsoft 的部落格:
在 IIS 7.5,IIS 7.0 中和 IIS 6.0 的 ASP.NET 執行緒使用方式

在 IIS 7.0 中的 ASP.net 擱置

?考

如需詳細資訊,請移至下列的 Microsoft 開發人員網路 (MSDN) 網站:
提升 ASP.NET 的效能

屬性

文章編號: 821268 - 上次校閱: 2013年2月6日 - 版次: 14.0
這篇文章中的資訊適用於:
  • Microsoft .NET Framework 2.0
  • Microsoft ASP.NET 1.1
  • Microsoft ASP.NET 1.0
關鍵字:?
kbprb kbmt KB821268 KbMtzh
機器翻譯
重要:本文是以 Microsoft 機器翻譯軟體翻譯而成,而非使用人工翻譯而成。Microsoft 同時提供使用者人工翻譯及機器翻譯兩個版本的文章,讓使用者可以依其使用語言使用知識庫中的所有文章。但是,機器翻譯的文章可能不盡完美。這些文章中也可能出現拼字、語意或文法上的錯誤,就像外國人在使用本國語言時可能發生的錯誤。Microsoft 不為內容的翻譯錯誤或客戶對該內容的使用所產生的任何錯誤或損害負責。Microsoft也同時將不斷地就機器翻譯軟體進行更新。
按一下這裡查看此文章的英文版本:821268
Microsoft及(或)其供應商不就任何在本伺服器上發表的文字資料及其相關圖表資訊的恰當性作任何承諾。所有文字資料及其相關圖表均以「現狀」供應,不負任何擔保責任。Microsoft及(或)其供應商謹此聲明,不負任何對與此資訊有關之擔保責任,包括關於適售性、適用於某一特定用途、權利或不侵權的明示或默示擔保責任。Microsoft及(或)其供應商無論如何不對因或與使用本伺服器上資訊或與資訊的實行有關而引起的契約、過失或其他侵權行為之訴訟中的特別的、間接的、衍生性的損害或任何因使用而喪失所導致的之損害、資料或利潤負任何責任。

提供意見

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com