Conflitto, scarse prestazioni e deadlock quando si effettuano chiamate a servizi Web da un'applicazione ASP.NET

Traduzione articoli Traduzione articoli
Identificativo articolo: 821268 - Visualizza i prodotti a cui si riferisce l?articolo.
Espandi tutto | Chiudi tutto

In questa pagina

Sintomi

Quando si effettuano chiamate a servizi Web da un'applicazione Microsoft ASP.NET, si verifichino contese, prestazioni ridotte e deadlock. I client potrebbero segnalare che le richieste di bloccarsi (o "blocco") o richiedono molto tempo per l'esecuzione. Se si sospetta un deadlock, il processo di lavoro pu˛ essere riciclato. Riceverai i seguenti messaggi di errore nel registro eventi dell'applicazione.
  • Se si utilizza Internet Information Services (IIS) 5.0, i seguenti messaggi di errore viene visualizzato nel registro applicazione:

       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.

  • Se si utilizza IIS 6.0, i seguenti messaggi di errore viene visualizzato nel registro applicazione:

       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'.

  • Se si utilizza IIS 6.0, i seguenti messaggi di errore viene visualizzato nel Registro di sistema:

       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>'.

╚ inoltre che venga visualizzato il seguente errore di eccezione quando dei messaggi si effettua una chiamata al metodo GetResponse :
"System. InvalidOperationException: Non erano abbastanza thread liberi nell'oggetto ThreadPool per completare la operazione".
╚ inoltre che venga visualizzato il seguente messaggio di errore di eccezione nel browser:
"HttpException (0x80004005): timeout richiesta out".
Nota. In questo articolo si applica anche alle applicazioni che inviano richieste di HttpWebRequest direttamente.

Cause

Questo problema pu˛ verificarsi perchÚ ASP.NET limita il numero thread di lavoro e thread di porta utilizzato per eseguire una chiamata richieste.

In genere, una chiamata a un servizio Web utilizza un thread di lavoro per eseguire il codice che invia la richiesta e un thread porta di completamento per ricevere la richiamata dal servizio Web. Tuttavia, se la richiesta viene reindirizzata o richiede l'autenticazione, la chiamata pu˛ utilizzare fino a due thread di lavoro e due thread di porta. Pertanto, Ŕ possibile esaurire ThreadPool gestito quando si verificano pi¨ chiamate al servizio Web nello stesso momento.

Ad esempio, si supponga che il pool di thread Ŕ limitata a 10 thread di lavoro e che tutti i thread di lavoro 10 stanno eseguendo codice Ŕ in attesa di un callback da eseguire. Il callback non pu˛ eseguire mai, perchÚ gli elementi di lavoro accodati al ThreadPool sono bloccati fino a quando un thread diventa disponibile.

Un'altra potenziale fonte di contesa Ŕ il parametro maxconnection che utilizza lo spazio dei nomi System.Net per limitare il numero di connessioni. In generale, Questo limite funziona come previsto. Tuttavia, se si tentano di apportare numerose applicazioni le richieste a un singolo indirizzo IP allo stesso tempo, il thread potrebbe essere necessario attendere una connessione disponibile.

Risoluzione

Per risolvere questi problemi, Ŕ possibile ottimizzare i seguenti parametri nel file Machine. config in base alla situazione:
  • maxWorkerThreads
  • minWorkerThreads
  • maxIoThreads
  • minFreeThreads
  • minLocalRequestFreeThreads
  • maxConnection
  • executionTimeout
Per risolvere questi problemi, effettuare le seguenti operazioni:
  • Limitare il numero di richieste ASP.NET che possono essere eseguite in contemporaneamente a circa 12 per CPU.
  • Consente di utilizzare liberamente i thread in ThreadPool richiamate dei servizi Web.
  • Selezionare un valore appropriato per il parametro maxconnections . Basare la selezione del numero di indirizzi IP e Domini applicazione vengono utilizzati.
Nota. Il suggerimento di limitare il numero di richieste ASP.NET a 12 per ogni CPU Ŕ arbitraria. Tuttavia, questo limite Ŕ dimostrato per la maggior parte delle applicazioni.

maxWorkerThreads e maxIoThreads

ASP.NET utilizza le seguenti impostazioni di configurazione di due Per limitare il numero massimo di thread di lavoro e thread di completamento sono utilizzato:
<processModel maxWorkerThreads="20" maxIoThreads="20">
I parametri maxWorkerThreads e maxIoThreads vengono implicitamente moltiplicati per il numero di CPU. Per esempio, se si dispongono di due processori, il numero massimo di thread di lavoro Ŕ il seguente codice:
2 * maxWorkerThreads

minFreeThreads e minLocalRequestFreeThreads

ASP.NET contiene inoltre la seguente configurazione impostazioni che determinano il numero di thread di lavoro e completamento thread della porta devono essere disponibili per avviare una richiesta remota o locale:
<httpRuntime minFreeThreads="8" minLocalRequestFreeThreads="8">
Se non sono disponibili thread sufficienti, la richiesta viene accodata fino a quando non sono sufficienti thread libero per effettuare la richiesta. Pertanto, ASP.NET verrÓ non eseguire pi¨ di numero di richieste contemporaneamente:
(maxWorkerThreads*numero di CPU)-minFreeThreads
Nota. Il parametro minFreeThreads e il parametro minLocalRequestFreeThreads non sono implicitamente moltiplicate per il numero di CPU.

minWorkerThreads

ASP.NET 1.0 Service Pack 3 e ASP.NET 1.1, ASP.NET contiene inoltre la seguente impostazione di configurazione che determina come molti thread di lavoro pu˛ essere immediatamente resi disponibili per un telecomando di servizio richiesta.
<processModel minWorkerThreads="1">
Thread controllate da questa impostazione pu˛ essere creata a una maggiore velocitÓ di thread di lavoro creato da CLR predefinita "ottimizzazione dei thread" funzionalitÓ. Questa impostazione consente di ASP.NET per gestire le richieste che possono essere riempire improvvisamente la coda di richieste ASP.NET a causa di un rallentamento su un back-end Server, un improvviso burst di richieste dal lato client o qualcosa di simile Ci˛ fa sý che un improvviso aumento del numero di richieste in coda. Il valore predefinito per il parametro minWorkerThreads Ŕ 1. Si consiglia di impostare il valore per il parametro minWorkerThreads il valore seguente.
minWorkerThreads = maxWorkerThreads / 2
Per impostazione predefinita, il parametro minWorkerThreads non Ŕ presente nel file Web. config o il file Machine. config. Questa impostazione viene implicitamente moltiplicata per il numero di CPU.

maxConnection

Il parametro maxconnection determina il numero di connessioni pu˛ essere reso di un indirizzo IP specifico. Il parametro viene visualizzato come segue:
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://65.53.32.230" maxconnection="12">
</connectionManagement>
Se il codice dell'applicazione fa riferimento l'applicazione mediante il nome host anzichÚ l'indirizzo IP, il parametro dovrebbe essere visualizzato come segue:
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://hostname" maxconnection="12">
</connectionManagement>
Infine, se l'applicazione Ŕ ospitata su una porta diversa dalla 80, il parametro deve includere la porta non standard nell'URI, simile al seguente:
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://hostname:8080" maxconnection="12">
</connectionManagement>
Le impostazioni per i parametri descritti in precedenza in questo articolo sono tutte a livello di processo. Tuttavia, l'impostazione del parametro maxconnection viene applicato al livello AppDomain. Per impostazione predefinita, PoichÚ questa impostazione viene applicata a livello di dominio applicazione, Ŕ possibile creare un massimo due connessioni a uno specifico indirizzo IP da ogni AppDomain nel processo.

executionTimeout

ASP.NET utilizza la seguente impostazione di configurazione per limitare il tempo di esecuzione della richiesta:
<httpRuntime executionTimeout="90"/>
╚ inoltre possibile impostare questo limite utilizzando la proprietÓ ScriptTimeout .

Nota. Se si aumenta il valore del parametro executionTimeout , potrebbe essere inoltre necessario modificare processModel responseDeadlockInterval impostazione del parametro.

Consigli

Le impostazioni consigliate in questa sezione potrebbero non funzionare per tutte le applicazioni. Tuttavia, le seguenti informazioni aggiuntive consentono di apportare le modifiche appropriate.

Se creazione di una chiamata al servizio Web a un unico indirizzo IP da ogni pagina ASPX Si consiglia di utilizzare le impostazioni di configurazione riportato di seguito:
  • Impostare i valori di parametro maxWorkerThreads e maxIoThreads a 100.
  • Impostare il valore del parametro maxconnection12 *N (dove N Ŕ il numero di CPU che Ŕ necessario).
  • Impostare i valori del parametro minFreeThreads88 *N e il parametro minLocalRequestFreeThreads per76 *N.
  • Set il valore di minWorkerThreads su 50. ╚ importante ricordare che minWorkerThreads non Ŕ presente nel file di configurazione per impostazione predefinita. ╚ necessario aggiungerlo.
Alcuni di questi suggerimenti comprendono una semplice formula che coinvolge il numero di CPU in un server. La variabile che rappresenta il numero di CPU del le formule Ŕ N. Per queste impostazioni, se hai attivato l'hyperthreading, Ŕ necessario utilizzare il numero di CPU logiche invece del numero di CPU fisiche. Ad esempio, se si dispone di un server con quattro processori con hyperthreading attivato, il valore di N nelle formule sarÓ 8 invece di 4.

Nota. Quando si utilizza questa configurazione, Ŕ possibile eseguire un massimo di 12 Richieste di ASP.NET per CPU contemporaneamente perchÚ 100-88 = 12. Pertanto, almeno 88 *N lavoro thread e 88 *N thread di porta di completamento disponibile per altri usi (ad esempio per le richiamate dei servizi Web).

Ad esempio, si dispone di un server con quattro processori e Hyper-Threading attivata. In base a queste formule, si utilizzerÓ i seguenti valori per il impostazioni di configurazione descritte in questo articolo.
<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>

Inoltre, quando si utilizza questa configurazione, sono disponibili 12 connessioni per ogni CPU per indirizzo IP per ogni dominio applicazione. Pertanto, nell'esempio che segue scenario, una contesa minima si verifica quando le richieste sono in attesa di connessioni e il ThreadPool non viene esaurito:
  • Il web ospita una sola applicazione (AppDomain).
  • Ogni richiesta per una pagina ASPX effettua una richiesta di servizio Web.
  • Tutte le richieste sono per lo stesso indirizzo IP.
Tuttavia, quando si utilizza questa configurazione, gli scenari che implicano uno dei seguenti utilizzeranno probabilmente troppe connessioni:
  • Sono richieste in pi¨ indirizzi IP.
  • Le richieste vengono reindirizzate (codice di stato 302).
  • Le richieste di autenticazione.
  • Le richieste vengono effettuate da pi¨ domini.
In questi scenari, Ŕ consigliabile utilizzare un valore inferiore per il parametro maxconnection e i valori pi¨ alti per il parametro minFreeThreads e il parametro minLocalRequestFreeThreads .

Status

Questo comportamento Ŕ legato alla progettazione.

Informazioni

Se si verifica una riduzione delle prestazioni e contesa su IIS 7.0 con ASP.NET, vedere il blog di Microsoft riportato di seguito:
Utilizzo dei Thread di ASP.NET in IIS 6.0, IIS 7.0 e IIS 7.5

Blocco di ASP.net in IIS 7.0

Riferimenti

Per ulteriori informazioni, visitare il seguente sito Web Microsoft Developer Network (MSDN):
Miglioramento delle prestazioni di ASP.NET

ProprietÓ

Identificativo articolo: 821268 - Ultima modifica: mercoledý 6 febbraio 2013 - Revisione: 1.0
Le informazioni in questo articolo si applicano a:
  • Microsoft .NET Framework 2.0
  • Microsoft ASP.NET 1.1
  • Microsoft ASP.NET 1.0
Chiavi:á
kbprb kbmt KB821268 KbMtit
Traduzione automatica articoli
Il presente articolo Ŕ stato tradotto tramite il software di traduzione automatica di Microsoft e non da una persona. Microsoft offre sia articoli tradotti da persone fisiche sia articoli tradotti automaticamente da un software, in modo da rendere disponibili tutti gli articoli presenti nella nostra Knowledge Base nella lingua madre dell?utente. Tuttavia, un articolo tradotto in modo automatico non Ŕ sempre perfetto. Potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli, pi¨ o meno allo stesso modo di come una persona straniera potrebbe commettere degli errori parlando una lingua che non Ŕ la sua. Microsoft non Ŕ responsabile di alcuna imprecisione, errore o danno cagionato da qualsiasi traduzione non corretta dei contenuti o dell?utilizzo degli stessi fatto dai propri clienti. Microsoft, inoltre, aggiorna frequentemente il software di traduzione automatica.
Clicca qui per visualizzare la versione originale in inglese dell?articolo: 821268
LE INFORMAZIONI CONTENUTE NELLA MICROSOFT KNOWLEDGE BASE SONO FORNITE SENZA GARANZIA DI ALCUN TIPO, IMPLICITA OD ESPLICITA, COMPRESA QUELLA RIGUARDO ALLA COMMERCIALIZZAZIONE E/O COMPATIBILITA' IN IMPIEGHI PARTICOLARI. L'UTENTE SI ASSUME L'INTERA RESPONSABILITA' PER L'UTILIZZO DI QUESTE INFORMAZIONI. IN NESSUN CASO MICROSOFT CORPORATION E I SUOI FORNITORI SI RENDONO RESPONSABILI PER DANNI DIRETTI, INDIRETTI O ACCIDENTALI CHE POSSANO PROVOCARE PERDITA DI DENARO O DI DATI, ANCHE SE MICROSOFT O I SUOI FORNITORI FOSSERO STATI AVVISATI. IL DOCUMENTO PUO' ESSERE COPIATO E DISTRIBUITO ALLE SEGUENTI CONDIZIONI: 1) IL TESTO DEVE ESSERE COPIATO INTEGRALMENTE E TUTTE LE PAGINE DEVONO ESSERE INCLUSE. 2) I PROGRAMMI SE PRESENTI, DEVONO ESSERE COPIATI SENZA MODIFICHE, 3) IL DOCUMENTO DEVE ESSERE DISTRIBUITO INTERAMENTE IN OGNI SUA PARTE. 4) IL DOCUMENTO NON PUO' ESSERE DISTRIBUITO A SCOPO DI LUCRO.

Invia suggerimenti

 

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