Contention, une dégradation des performances et blocages lorsque vous effectuez des appels aux services Web à partir d'une application ASP.NET

Traductions disponibles Traductions disponibles
Numéro d'article: 821268 - Voir les produits auxquels s'applique cet article
Agrandir tout | Réduire tout

Sommaire

Symptômes

Lorsque vous effectuez des appels aux services Web à partir d'une application Microsoft ASP.NET, vous pouvez rencontrer des conflits, une dégradation des performances et des blocages. Les clients peuvent signaler que les demandes de cesser de répondre (ou « se bloquer ») ou longue à exécuter. Si un blocage est suspects, le processus de travail peut être recyclé. Vous pouvez recevoir des messages suivants dans le journal des événements application.
  • Si vous utilisez Internet Information Services (IIS) 5.0, les messages suivants s'affiche dans le journal applications :

       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.

  • Si vous utilisez IIS 6.0, les messages suivants s'affiche dans le journal applications :

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

  • Si vous utilisez IIS 6.0, les messages suivants s'affiche dans le journal système :

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

Vous pouvez également recevoir l'erreur d'exception lorsque des messages vous effectuez un appel à la méthode HttpWebRequest.GetResponse :
« System.InvalidOperationException : Se sont pas suffisamment de threads libres dans l'objet ThreadPool pour terminer le opération".
Le message d'erreur exception suivant peut s'afficher dans le navigateur :
« HttpException (0 x 80004005): délai de la demande sorti ».
Remarque : Cet article s'applique également aux applications qui font directement des requêtes HttpWebRequest .

Cause

Ce problème peut se produire car ASP.NET limite le nombre des threads de travail et les threads de port de terminaison qu'un appel peut utiliser pour exécuter demandes.

En règle générale, un appel à un service Web utilise un thread de travail pour exécuter le code qui envoie la demande et un thread de port de terminaison pour recevoir le rappel du service Web. Toutefois, si la demande est redirigée ou requiert une authentification, l'appel peut utiliser jusqu'à deux threads de travail et deux threads de port de terminaison. Par conséquent, vous pouvez épuiser le pool de threads managé lorsque plusieurs appels au service Web se produisent en même temps.

Par exemple, supposons que le pool de threads est limité à 10 threads de travail et que toutes les 10 threads de travail exécutent du code qui est en attente d'un rappel à exécuter. Le rappel ne peut jamais exécuter, car tous les éléments de travail qui sont en attente pour le pool de threads sont bloqués jusqu'à ce qu'un thread devient disponible.

Une autre source potentielle de conflit est le paramètre maxconnection l'espace de noms System.Net utilise pour limiter le nombre de connexions. En règle générale, Cette limite fonctionne comme prévu. Toutefois, si de nombreuses applications tentent d'apporter de nombreuses demandes en une seule adresse IP en même temps, threads devront peut-être attendre une connexion disponible.

Résolution

Pour résoudre ces problèmes, vous pouvez régler les paramètres suivants dans le fichier Machine.config pour mieux adaptés à votre situation :
  • maxWorkerThreads
  • minWorkerThreads
  • maxIoThreads
  • minFreeThreads
  • minLocalRequestFreeThreads
  • maxconnection
  • executionTimeout
Pour résoudre ces problèmes, effectuez les actions suivantes :
  • Limiter le nombre de demandes ASP.NET qui peut s'exécuter à le même temps à environ 12 par UC.
  • Autoriser les rappels de service Web à utiliser des threads dans le pool de threads.
  • Sélectionnez une valeur appropriée pour le paramètre maxconnections . Votre sélection de base sur le nombre d'adresses IP et Domaines d'application sont utilisés.
Remarque : La recommandation visant à limiter le nombre de demandes ASP.NET à 12 par UC est quelque peu arbitraire. Toutefois, cette limite s'est avérée satisfaisante pour la plupart des applications.

maxWorkerThreads et maxIoThreads

ASP.NET utilise les paramètres de configuration suivants Pour limiter le nombre maximal de threads de travail et de threads d'achèvement utilisé :
<processModel maxWorkerThreads="20" maxIoThreads="20">
Le paramètre maxWorkerThreads et maxIoThreads sont implicitement multipliés par le nombre d'UC. Pour exemple, si vous disposez de deux processeurs, le nombre maximal de threads de travail est les éléments suivants :
2 * maxWorkerThreads

minFreeThreads et minLocalRequestFreeThreads

ASP.NET contient également la configuration suivante paramètres qui déterminent le nombre de threads de travail et de fin des threads de port doit être disponible pour le lancement d'une demande distante ou une demande locale :
<httpRuntime minFreeThreads="8" minLocalRequestFreeThreads="8">
Si suffisamment de threads ne sont pas disponibles, la demande est en attente jusqu'à ce que suffisamment de threads est libres de faire la demande. Par conséquent, ASP.NET sera s'exécute pas plus que le nombre de demandes en même temps :
(maxWorkerThreads*nombre d'unités centrales)-minFreeThreads
Remarque : Le paramètre minFreeThreads et minLocalRequestFreeThreads ne sont pas implicitement multipliés par le nombre de processeurs.

minWorkerThreads

Depuis ASP.NET 1.0 Service Pack 3 et ASP.NET 1.1, ASP.NET contient également le paramètre de configuration suivant qui détermine comment nombre de threads de travail peut se faire immédiatement disponible pour une télécommande de service demande.
<processModel minWorkerThreads="1">
Threads qui sont contrôlées par ce paramètre peut être créé à un rythme beaucoup plus rapide que threads de travail sont créés à partir du CLR par défaut » « réglage de threads capacités. Ce paramètre permet à ASP.NET pour traiter les demandes qui peuvent être remplissage soudainement la file d'attente de la demande ASP.NET en raison d'un ralentissement d'un back-end serveur, une soudaine de demandes à partir de l'extrémité cliente ou quelque chose de similaire qui provoquerait une augmentation soudaine du nombre de demandes dans la file d'attente. Le valeur par défaut pour le paramètre minWorkerThreads est 1. Nous vous recommandons de définir la valeur du paramètre minWorkerThreads à la valeur suivante.
minWorkerThreads = maxWorkerThreads / 2
Par défaut, le paramètre minWorkerThreads n'est pas présent dans le fichier Web.config ou le fichier Machine.config. Ce paramètre est implicitement multiplié par le nombre de Unités centrales.

maxconnection

Le paramètre maxconnection détermine le nombre de connexions peut être apportée à un adresse IP spécifique. Le paramètre s'affiche comme suit :
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://65.53.32.230" maxconnection="12">
</connectionManagement>
Si le code de l'application fait référence à l'application par nom d'hôte au lieu de l'adresse IP, le paramètre doit apparaître comme suit :
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://hostname" maxconnection="12">
</connectionManagement>
Enfin, si l'application est hébergée sur un port autre que 80, le paramètre doit inclure le port non standard dans l'URI, semblable au suivant :
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://hostname:8080" maxconnection="12">
</connectionManagement>
Les paramètres pour les paramètres qui sont décrits plus haut dans cet article sont tous au niveau du processus. Toutefois, la valeur du paramètre maxconnection s'applique au niveau AppDomain. Par défaut, Étant donné que ce paramètre s'applique au niveau du domaine d'application, vous pouvez créer un maximum deux connexions à une adresse IP spécifique à partir de chaque domaine d'application dans votre processus.

executionTimeout

ASP.NET utilise les paramètres de configuration suivants pour limiter la durée d'exécution de requête :
<httpRuntime executionTimeout="90"/>
Vous pouvez également définir cette limite à l'aide de la propriété Server.ScriptTimeout .

Remarque : Si vous augmentez la valeur du paramètre executionTimeout , vous devrez peut-être également modifier le processModel responseDeadlockInterval valeur du paramètre.

Recommandations

Les paramètres qui sont recommandés dans cette section peut ne pas fonctionnent pour toutes les applications. Toutefois, les informations supplémentaires suivantes peuvent vous aider à effectuer les réglages appropriés.

If vous effectuez un appel de service Web à une adresse IP unique à partir de chaque page ASPX, Microsoft vous recommande d'utiliser les paramètres de configuration suivants :
  • Définissez les valeurs de paramètre maxWorkerThreads et maxIoThreads à 100.
  • Définir la valeur du paramètre maxconnection à 12 *N (où N est le nombre de processeurs qui vous avez).
  • Définir les valeurs du paramètre minFreeThreads à 88 *N et minLocalRequestFreeThreads à76 *N.
  • Ensemble la valeur de minWorkerThreads à 50. N'oubliez pas que minWorkerThreads n'est pas dans le fichier de configuration par défaut. Vous devez l'ajouter.
Certains Ces recommandations impliquent une formule simple qui inclut le nombre des processeurs sur un serveur. La variable qui représente le nombre d'UC dans le formules est N. Pour ces paramètres, si vous avez activé, la technologie hyperthreading Vous devez utiliser le nombre de processeurs logiques au lieu du nombre de processeurs physiques. Par exemple, si vous avez un serveur à quatre processeurs avec hyperthreading est activée, puis la valeur de N dans les formules sera 8 au lieu de 4.

Remarque : Lorsque vous utilisez cette configuration, vous pouvez exécuter un maximum de 12 Demandes ASP.NET par UC en même temps, car 100-88 = 12. Par conséquent, au moins 88 *N travailleur threads et 88 *N threads de port de terminaison sont disponible pour d'autres utilisations (par exemple, en ce qui concerne les rappels de service Web).

Par exemple, vous disposez d'un serveur avec quatre processeurs et hyperthreading activé. En fonction de ces formules, utilisez les valeurs suivantes pour le paramètres de configuration qui sont mentionnées dans cet article.
<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>

En outre, lorsque vous utilisez cette configuration, 12 connexions sont disponibles par UC par adresse IP pour chaque domaine d'application. Par conséquent, dans les éléments suivants scénario, très peu de conflit se produit lorsque les demandes sont en attente de connexions et le pool de threads n'est pas épuisé :
  • Le site web héberge une seule application (AppDomain).
  • Chaque demande de page ASPX effectue une demande de service Web.
  • Toutes les demandes sont à la même adresse IP.
Toutefois, lorsque vous utilisez cette configuration, des scénarios qui impliquent une des opérations suivantes utiliseront probablement trop de connexions :
  • Les demandes sont en plusieurs adresses IP.
  • Les demandes sont redirigées (code d'état 302).
  • Demandes requièrent l'authentification.
  • Demandes sont effectuées à partir de plusieurs domaines d'application.
Dans ces scénarios, il est conseillé d'utiliser une valeur inférieure pour le paramètre maxconnection et des valeurs élevées pour le paramètre minFreeThreads et minLocalRequestFreeThreads .

Statut

Cela comportement est voulu par la conception.

Plus d'informations

Si vous rencontrez une baisse des performances et la contention sur IIS 7.0 et ASP.NET, consultez les blogs de Microsoft suivants :
Utilisation de Thread ASP.NET sur IIS 7.5, IIS 7.0 et IIS 6.0

Blocage de ASP.net dans IIS 7.0

Références

Pour plus d'informations, consultez le site Web Microsoft Developer Network (MSDN) suivant :
Amélioration des performances ASP.NET

Propriétés

Numéro d'article: 821268 - Dernière mise à jour: mercredi 6 février 2013 - Version: 1.0
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft .NET Framework 2.0
  • Microsoft ASP.NET 1.1
  • Microsoft ASP.NET 1.0
Mots-clés : 
kbprb kbmt KB821268 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 821268
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

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