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

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 :Le message d'erreur exception suivant peut s'afficher dans le navigateur :Remarque : Cet article s'applique également aux applications qui font directement des requêtes HttpWebRequest .

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.

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é : 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 :

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

Cela comportement est voulu par la conception.

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

Pour plus d'informations, consultez le site Web Microsoft Developer Network (MSDN) suivant :